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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Speech and multimedia 
Transmission Quality (STQ). 

The present document is part 2 of a multi-part deliverable covering the QoS aspects for popular services in mobile 
networks, as identified below: 



Part 1: 


"Assessment of Quality of Service"; 


Part 2: 


"Definition of Quality of Service parameters and their computation" 


Part 3: 


"Typical procedures for Quality of Service measurement equipment"; 


Part 4: 


"Requirements for Quality of Service measurement equipment"; 


Part 5: 


"Definition of typical measurement profiles"; 


Part 6: 


"Post processing and statistical methods"; 


Part?: 


"Network based Quality of Service measurements". 



Part 1 builds an umbrella document for this multi-part deliverable. It summarizes the basics of Quality of Service, 
always seen from the user's perspective. Differences to Quality of Experience (QoE) are also discussed. In extension to 
generic definitions, specific definitions for this multi-part deliverable are stated here. Furthermore, it gives guidance to 
assure that QoS assessments can be conducted in a meaningful way and proposes an according process. 

The present document defines QoS parameters and their computation for popular services in mobile networks. The 
parameter definition is split into several parts. It contains an abstract definition which gives a generic description of the 
parameter, an abstract equation and the corresponding user and technical trigger points. 

The harmonized definitions given in part 2 are considered as prerequisites for the comparison of QoS measurements and 
measurement results. 

Part 3 describes the measurement procedures needed to perform the measurements of QoS parameters in line with the 
definitions given in part 2, applying the test profiles defined in part 5. 

Part 4 defines the minimum requirements of QoS measurement equipment for mobile networks in the way that the 
values and trigger points needed to compute the QoS parameter as defined in part 2 can be measured following the 
procedures defined in part 3. Test equipment fulfilling the specified minimum requirements will allow performing the 
proposed measurements in a reliable and reproducible way. 

Part 5 specifies typical measurement profiles which are required to enable benchmarking of different mobile networks 
both within and outside national boundaries. 

Part 6 describes procedures to be used for statistical calculations in the field of QoS measurement of mobile networks 
using probing systems. 

Part 7 describes how Quality of Service measurements should be done inside the network without direct access to the 
end point terminal. 
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Introduction 

The present document defines quality of service (QoS) parameters and their computation based on field measurements. 

This means that the measurement of these QoS parameters is done from the user's point of view (full end-to-end 
perspective, taking into account the needs of testing). 

Each parameter definition is split into several parts. It contains an abstract definition which gives a generic description 
of the parameter, an abstract equation and the corresponding user and technical trigger points. 
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1 Scope 

The present document defines QoS parameters and their computation for popular services in mobile networks. 

The harmonized definitions given in the present document are considered as the prerequisite for the comparison of QoS 
measurements and their results. 

It is assumed that the end user can handle his mobile terminal and the services he wants to use (operability is not 
evaluated). 

The computation of specific QoS parameters may vary depending on the respective mobile network, e.g. GSM or 3GPP 
specified 3G system. In this case a respective notification is provided. 

Other standardisation bodies may request an approved document containing specific QoS parameters to be used as 
reference in their documents. Therefore, the present document may contain incomplete QoS parameter definitions, 
e.g. giving a description but missing technical trigger points. Such points are marked as "tbd" (to be defined) and will be 
updated as soon as possible. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http :// docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ITU-T Recommendation P. 862: "Perceptual evaluation of speech quality (PESQ): An objective 

method for end-to-end speech quality assessment of narrow-band telephone networks and speech 
codecs". 

[2] WAPTM-206-MMSCTR-200201 15-a: "Wireless AppHcation Protocol; Multimedia Messaging 

Service; Client Transactions Specification". 

[3] IETF RFC 5322 (2008): "Internet Message Format". 

[4] Void. 

[5] ETSI TS 102 250-3: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks; Part 3: Typical procedures for Quality of Service 
measurement equipment" . 

[6] ITU-R Recommendation BS. 1387-1 : "Method for objective measurements of perceived audio 

quality" . 

[7] IETF RFC 3550 (2003): "RTP: A Transport Protocol for Real-Time Applications". 

[8] IETF RFC 2326 (1998): "Real Time Streaming Protocol (RTSP)". 

[9] ITU-T Recommendation P.862.1: "Mapping function for transforming P.862 raw result scores to 

MOS-LQO". 
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[10] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Teleconmiunications System (UMTS); LTE; Mobile radio interface Layer 3 specification; Core 
network protocols; Stage 3 (3GPP TS 24.008 Release 7)". 

[11] ETSI TS 145 008: "Digital cellular teleconmiunications system (Phase 2+); Radio subsystem link 

control (3GPP TS 45.008 Release 6)". 

[12] ETSI TS 129 002: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Teleconmiunications System (UMTS); Mobile Application Part (MAP) specification 
(3GPP TS 29.002 Release 6)". 

[13] ETSI TS 123 246: "Universal Mobile Telecommunications System (UMTS); LTE; Multimedia 

Broadcast/Multicast Service (MBMS); Architecture and functional description 
(3GPP TS 23.246 Release 6)". 

[14] OMA: "Push to talk over Cellular (PoC) - Architecture" (approved Version 1.0.4, 

December 3'^ 2009). 

[15] OMA: "PoC User Plane" (approved Version 1.0.4, December 3'^ 2009). 

[16] OMA: "OMA PoC Control Plane" (approved Version 1.0.4, December 3'^ 2009). 

[17] IETF RFC 3903 (2004): "Session Initiation Protocol (SIP) Extension for Event State Publication". 

[18] ITU-T Recommendation P. 862.2: "Wideband extension to Recommendation P.862 for the 

assessment of wideband telephone networks and speech codecs". 

[19] ITU-T Recommendation P.862. 3: "Application guide for objective quality measurement based on 

Recommendations P.862, P.862. 1 and P.862.2". 

[20] ITU-T Recommendation E.800: "Definitions of terms related to quality of service". 

[21] ETSI TS 127 007: "Digital cellular telecommunications system (Phase 2-f); Universal Mobile 

Telecommunications System (UMTS); LTE; AT command set for User Equipment (UE) 
(3GPP TS 27.007)". 

[22] ETSI TS 125 304: "Universal Mobile Telecommunications System (UMTS); User Equipment 

(UE) procedures in idle mode and procedures for cell reselection in connected mode 
(3GPP TS 25.304)". 

[23] ITU-T Recommendation P.800.1: "Mean Opinion Score (MOS) terminology". 

[24] ETSI TS 127 005: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Use of Data Terminal Equipment - Data Circuit 
terminating Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell 
Broadcast Service (CBS) (3GPP TS 27.005)". 

[25] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2 
(3GPP TS 23.228)". 

[26] ITU-R Recommendation BT. 1359-1: "Relative timing of sound and vision for broadcasting". 

[27] ETSI EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V-fD); Part 2: Air 

Interface (AI)". 

[28] ETSI EN 300 392-5: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D) and Direct 

Mode Operation (DM0); Part 5: Peripheral Equipment Interface (PEI)". 

[29] IETF RFC 5245 (2010): "Interactive Connectivity EstabHshment (ICE): "A Protocol for Network 

Address Translator (NAT) Traversal for Offer/ Answer Protocols". 

[30] IETF RFC 5389: "Session Traversal Utilities for NAT (STUN)". 

[31] ITU-T Recommendation P. 863: "Perceptual objective listening quality assessment". 
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[32] OMA: "Enabler Release Definition for Push-to-Talk over Cellular" (approved Version 1.0.4, 

December 3rd, 2009). 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TS 102 250-5: "Speech and multimedia Transmission Quality Aspects (STQ); QoS aspects 

for popular services in mobile networks; Part 5: Definition of typical measurement profiles". 

[i.2] ETSI Directives. 

NOTE: Available at http ://portal . etsi . or g/Directi ves/home . asp . 



3 Definitions and abbreviations 
3.1 Definitions 

For all QoS parameter definitions within the present document, the second column of the trigger point table - "Trigger 
Points" (from user's point of view) - is mandatory (if present) for all QoS parameter definitions. In the case that the 
measurement system is capable of tracking details presented in the third column - "Technical Description" - the specific 
points indicated are also mandatory. 

For the purposes of the present document, the terms and definitions given in the ETSI Directives [i.2] and the following 
apply: 

1-1 PoC session: feature enabling a PoC user to establish a PoC session with another PoC user 

ad-hoc PoC group session: PoC session for multiple PoC users that does not involve the use or definition of a 
pre-arranged or chat PoC group 

AT interface: interface within a User Equipment (UE) between a Terminal Equipment (TE), which can be an external 
measurement equipment, and a Mobile Termination (MT) used for sending Attention (AT) commands from the TE to 
the MT and receiving responses or indications from the MT at the TE 

NOTE 1 : The AT interface is commonly also referred as R reference point. 

NOTE 2: In TETRA, the AT interface is referred as Peripheral Equipment Interface (PEI), see EN 300 392-5 [28]. 

automatic answer: terminal accepts the invitation automatically if resources are available 

bearer: resource in the broadcast transport system that allows the transmission of data to the terminal or from the 
terminal 

NOTE: We distinguish between Broadcast Bearer and Mobile Network Bearer. The latter one is synonymously 
referred to as Interactivity Channel. 

bootstrapping: mechanism where the broadcast signal is accessed for the first time within a service usage 

NOTE: Parts of this procedure are the synchronization to the signal and its decoding so that afterwards a list of 
available channels is accessible and presented to the user. 

bootstrapping bearer: bearer on which the bootstrapping procedure is executed 

broadcast bearer: bearer supporting the broadcast service (e.g. DVB-H, MBMS, etc.) 

NOTE: The broadcast signal is transmitted via this bearer. 

chat PoC group: persistent group in which each member individually joins the PoC session i.e. the establishment of a 
PoC session to a chat PoC group does not result in other members of the chat PoC group being invited 
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chat PoC group session: PoC session established to a chat PoC group 

confirmed indication: signalling message returned by the PoC server to confirm that the PoC server, all other network 
elements intermediary to the PoC server and a terminating terminal are able and willing to receive media 

content: in case of a FTP session content is a file, in case of a HTTP session it is a web page and the content of an 
e-Mail session is the text of the e-Mail 

e-mail: the term "e-mail" refers to a message conforming to [3] consisting of a header section ("e-mail header") and a 
body ("e-mail body"), e-mail attachments are considered as part of the e-mail body 

ESG retrieval bearer: bearer which is used to retrieve the ESG information 

last data packet: packet that is needed to complete the transmission of the content on the receiving side 

NOTE: For FTP download, the last data packet contains a set TCP FIN flag bit. 
manual answer: PoC user accepts the invitation manually 

mobile broadcast service: end-to-end system for delivery of any types of digital content and services towards a mobile 
terminal using IP-based mechanisms 

mobile network bearer: bearer provided by a mobile network operator (e.g. GSM, GPRS, UMTS, etc.) to establish 
interactivity within the Mobile Broadcast Service 

on-demand session: PoC session set-up mechanism in which all media parameters are negotiated at PoC session 
establishment 

NOTE: The on-demand sessions are defined by the OMA PoC specification [32] as mandatory for PoC enabled 
user equipment, whereas pre-established sessions are defined as optional. 

PoC session: established connection between PoC users where the users can communicate using speech one at a time 

PoC user: user of the PoC service 

pre-arranged PoC group session: persistent PoC session that has an associated set of PoC members 

NOTE: The establishment of a PoC Session to a pre-arranged PoC group results in inviting all members of the 
defined group. 

pre-established session: SIP session established between the terminal and the PoC server that performs the 
participating PoC function 

NOTE: The terminal establishes the pre-established session prior to making requests for PoC sessions to other 
PoC users. 

service provider: operating company of a PLMN 

service user: end user who uses the services of a PLMN by means of a UE, e.g. a mobile phone or data card 

talk burst: flow of media, e.g. some seconds of speech, from a terminal while that has the permission to send media 

talk burst control: control mechanism that arbitrates requests from the terminals, for the right to send media 

TBCP Talk Burst Granted: used by the PoC server to notify the terminal that it has been granted permission to send a 
talk burst 

NOTE: See [14] for possible floor states. 

TBCP Talk Burst Idle: used by the PoC server to notify all terminals that no one has the permission to send a talk 
burst at the moment and that it may accept the "TBCP Talk Burst Request" message 

NOTE: See [14] for possible floor states. 

TBCP Talk Burst Request: used by the terminal to request permission from the PoC server to send a talk burst 

NOTE: See [14] for possible floor states. 
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terminal: shall be used when referring to a PoC enabled user equipment which is a user equipment implementing a PoC 
client 

NOTE: See [13]. 

unconfirmed indication: indication returned by the PoC server to confirm that it is able to receive media and believes 
the terminal is able to accept media 

NOTE: The PoC server sends the unconfirmed indication prior to determining that all egress elements are ready 
or even able to receive media. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3G 3^^ Generation 

3GPP Third Generation Partnership Project 

AAL2 Asynchronous Transfer Mode Adaptation Layer type 2 

ACK Acknowledgement 

ACM Address Complete 

ALCAP Access Link Control Application Protocol 

AM Acknowledged Mode 

APN Access Point Name 

AT Command ATtention Command 

ATA ATtention Answer 

ATD ATtention Dial 

ATH ATtention Hang-up 

CC Call Control 

CCCH Common Control Channel 

CLI Calling Line Identity 

CLIP Calling Line Identity Presentation 

CMCE Circuit Mode Control Entity 

CPN Calling Party Number 

CRLF Carriage Return Line Feed 

CS Circuit Switched 

CSCF Call Session Control Function 

CUT PoC Session CUT-off (PoC) 

DCCH Dedicated Control CHannel 

DCE Data Circuit-terminating Equipment 

DCH Data CHannel 

DCH-FP Data CHannel Frame Protocol 

DELAY Talk Burst DELAY (PoC) 

DeREG PoC DeREGistration (PoC) 

DLDT DownLink Direct Transfer 

DNS Domain Name Service 

DP Detection Point 

DROP Talk Burst DROP (PoC) 

DT Direct Transfer 

DTE Data Terminal Equipment 

DVB-H Digital Video Broadcasting - Handheld 

EPG Electronic Program Guide 

ESG Electronic Service Guide 

EACH Forward Access CHannel 

FIN TCP FINish flag 

FTP File Transfer Protocol 

FR Failure Ratio 

GGSN Gateway GPRS Support Node 

GMM GPRS Mobility Management 

GMSC Gateway Mobile Switching Centre 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 
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HLR Home Location Register 

HSS Home Subscriber Server 

HTTP HyperText Transfer Protocol 

lAM Initial Address Message 

ICMP Internet Control Message Protocol 

IMEI International Mobile Equipment Identification 

IMS IP Multimedia Subsystem 

INIT PoC Session INITiation 

IP Internet Protocol 

ISUP ISDN User Part 

KPI Key Performance Indicator 

LI Layer 1 

LEAVE PoC Session LEAVing 

LLC Logical Link Control 

MBMS Multimedia Broadcast/Multicast Service 

MGW Media GateWay 

MM Mobility Management 

MMS Multimedia Messaging Service 

MMSC Multimedia Messaging Service Centre 

MO Mobile Originated 

MOS Mean Opinion Score 

MOS-LQO Mean Opinion Score - Listening speech Quality Objective 

MS Mobile Station 

MSC Mobile Switching Centre 

MT Mobile Terminated 

MTSI Multimedia Telephony Service for IMS 

NEAP Node B Application Part 

OMA Open Mobile Alliance 

PDP Packet Data Protocol 

PDU Protocol Data Unit 

PEP Performance Enhancement Proxy 

PLMN Pubhc Land Mobile Network 

PoC Push to talk over Cellular 

POPS Post Office Protocol version 3 

PS Packet Switched 

PtS Push to Speech 

PTT Push To Talk 

PUB PoC PUBhsh 

QoS Quality of Service 

RAB Radio Access Bearer 

RACH Random Access CHannel 

RANAP Radio Access Network Application Protocol 

RAS Remote Access Service 

REG long PoC REGistration and Pubhsh 

REG PoC REGistration 

REL Release Message 

RNC Radio Network Controller 

RR Radio Resources 

RRC Radio Resource Control 

RTCP Real Time Control Protocol 

RTP Real Time Protocol 

RTSP Real Time Streaming Protocol 

RX Reception 

SCCP Signalling Connection Control Part 

SDCCH Stand-alone Dedicated Control CHannel 

SDP Session Description Protocol 

SDS Short Data Service 

SDS-TL Short Data Service-Transport Layer 

SDSC Short Data Service Centre 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SM Session Management 
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SMS 


Short Message Service 


SMSC 


Short Message Service Centre 


SMTP 


Simple Mail Transfer Protocol 


SNDCP 


SubNetwork Dependent Convergence Protocol 


SpQ 


Speech Quality 


SRTP 


Secure Real-time Transfer Protocol 


SSID 


Service Set Identifier 


SwMI 


Switching and Management Infrastructure 


SYN 


TCP SYNchronize flag 


TBCP 


Talk Burst Control Protocol 


TBF 


Temporary Block Flow 


TCP 


Transmission Control Protocol 


TCP-HS 


Transmission Control Protocol HandShake 


TE 


Terminal Equipment 


TETRA 


TErrestrial Trunked RAdio 


TX 


Transmission 


UDP 


User Datagram Protocol 


UE 


User Equipment 


ULDT 


UpLink Direct Transfer 


UM 


Unacknowledged Mode 


UMTS 


Universal Mobile Teleconmiunications System 


VLR 


Visitor Location Register 


VT 


Video Telephony 


WAE 


Wireless Application Environment 


WAP^^ 


Wireless Application Protocol 


WCDMA 


Wideband Code Division Multiple Access 


WGR 


WAP Get Request 


WSL 


Wireless Session Layer 


WSP 


Wireless Session Protocol 


WTLS 


Wireless Transport Layer Security 


WTP 


Wireless Transport Protocol 



4 QoS Parameter Basics 
4.1 General Overview 

Figure 1 shows a model for quality of service parameters. This model has four layers. 

The first layer is the Network Availability, which defines QoS rather from the viewpoint of the service provider than the 
service user. The second layer is the Network Access. From the service user's point of view this is the basic requirement 
for all the other QoS aspects and parameters. The third layer contains the other three QoS aspects Service Access, 
Service Integrity and Service Retainability. The different services are located in the fourth layer. Their outcome are the 
QoS parameters. 
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Figure 1 : QoS aspects and the corresponding QoS parameters 



4.2 



FTP, HTTP and E-Mail Issues 



Currently two main views about the best way to reflect the user's experience for these services are in place: 

• One preferring the payload throughput philosophy and the other preferring the transaction throughput 
philosophy: 

Method A defines trigger points which are as independent as possible from the service used, therefore 
representing a more generic view (payload throughput). 

Method B defines trigger points on application layer, therefore representing a more service oriented view 
(transaction throughput). 

An example of the different trigger points defined for each set is illustrated in Figure 2 and Figure 3. The start trigger 
point for the Mean Data Rate for Web browsing is either the reception of the first packet containing data content 
(Method A) or the sending of the HTTP GET command (Method B). 

A field test system compliant to the present document shall measure both sets (Method A and B) of QoS indicators 
using commercial UEs. 

In addition a set of technical QoS indicators is defined that covers the attach and PDP context activation procedure. 
Field test systems shall be able to measure these QoS indicators. 
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Figure 2: QoS parameters version A (example: HTTP via GPRS) 
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Figure 3: QoS parameters version B (Example: HTTP via GPRS) 
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4.2.1 Performance Enhancement Proxies 

Performance Enhancement Proxies (PEP, also called accelerators) are network elements employed to improve the 
performance of the data services offered by the mobile operator. To achieve this goal such proxies typically employ 
different techniques: 

• Content filtering (elimination of content of a certain type, e.g. audio files). 

• Lossless content compression (e.g. compression of HTML or other text like files). 

• Lossy content compression (e.g. recalculation of JPG files to a lower colour deepness or resolution of detail 
richness). 

• Protocol optimization (e.g. for HTTP, POPS). 

By these means PEPs achieve a reduction of the amount of data transferred from or to the end-user and thus a reduction 
of the transfer time. Some of these techniques will have an impact on content integrity and/or on the content quality as 
perceived by the end-user. 

The following guidelines apply whenever Performance Enhancement Proxies are employed: 

• When reporting mean data rates it shall be observed that the actual amount of transferred user data (rather than 
the original amount of hosted data) is used for calculations. 

• When reporting session times it is recommended that an indication of the impact of the enhancement 
techniques on the content quality is given - e.g. the content compression ratio (amount of received and 
uncompressed content compared to the amount of originally hosted content). 

• It is recommended to indicate the impact of the enhancement techniques on content integrity, e.g. eliminated 
or modified content. 

4.3 Timeouts 

In day-to-day testing it is necessary to define timeout values for specific service transactions as testing time is a limited 
resource. These timeouts have a direct impact on the respective QoS parameters. A small timeout value for instance will 
result in higher failure ratio parameters while a large timeout value will lead to lower throughput rates and higher 
transfer times, statistically. 

With respect to the present document an expired timeout means that the stop trigger point given in the definition of the 
QoS parameter definition was not reached. 

In case not timeout is stated in a technical description/protocol part for an expected response, this shall be understood 
implicitly in the sense that the response needs to be received within a predefined time. Otherwise, it is regarded as not 
having been received at all. 

For more information on detailed timeout values for specific services please refer to TS 102 250-5 [i.l]. 

4.4 Trigger points 

In the present document, trigger point definitions are part of each QoS parameter definition. 

For each trigger point definition, information concerning the technical description / protocol part is given as part of the 
definition. In particular, each trigger point may contain more than one technical description / protocol part, reflecting 
for example different reference points and / or protocol layers. 

For example, a trigger point may be defined both by 'AT commands and responses' at the AT interface and 'layer 3 
messages'. In such cases and if not stated differently in the respective subsection defining the trigger point, these 
descriptions / protocol parts are equally valid. 

Measurement data from measurements of QoS parameters being based on different technical descriptions / protocol 
parts for the same trigger point shall not be compared directly. 
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In general, for the calculation of QoS parameters, it is recommended to use related trigger points in a corresponding 
way, i.e. utilising the same protocol layer and reference point for the start and stop trigger, respectively. 

In case more than one technical description / protocol part is present, it is up to the reader to choose the technical 
description / protocol part suiting best the actual needs and / or situation. For instance, one of the related reference 
points might not be accessible for measurements whereas some other reference point is. 



5 Service independent QoS Parameters 

5.1 Radio Network Unavailability [%] 
5.1.1 Abstract Definition 



Probability that the mobile services are not offered to a user. 

5.1.2 Abstract Equation 



Radio Network Unavailability [%] = 



probing attempts with mobile services not available 
all probing attempts 



xlOO 



5.1.3 Trigger Points 

GSM: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical condition 


Probing attempt 


Not applicable. 


Check CI -Criteria. 


Mobile services available 


Not applicable. 


GSM: CI -Criteria > 0. Any emergency camping 
on any other than the target networks is 
considered as no network. 


Mobile services not available 


Technical condition not met. 


GPRS: 


Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical condition 


Probing attempt 


Not applicable. 


Check GRPS specific signalling contained 
within System Information 3. 


Mobile service available 


Not applicable. 


Specific signalling contained in System 
Information 3 exists on cell selection. 


Mobile service not available 


Technical condition not met. 


UMTS (WCDMA): 


Event from abstract equation 


Trigger point from user's 
point of view 


Technical condition 


Probing attempt 


Not applicable. 


Check S-Criteria. 


Mobile services available 


Not applicable. 


WCDMA: S-Criteria satisfied. Any emergency 
camping on any other than the target networks 
is considered as no network. 


Mobile services not available 


Technical condition not met. 
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NOTE 1: For information on how the CI -criteria is defined please refer to TS 145 008 [1 1]. 

NOTE 2: For information on how the S-criteria is defined please refer to TS 125 304 [22]. 

NOTE 3: When the test mobile operates in dual-mode (GSM/UMTS) than the judgement on Radio Network 
Unavailability is made with respect to the radio access technology in which the test device is at the 
moment of the check. 

NOTE 4: The target networks could constitute of more than one network, e.g. to cover national or international 
roaming. 

5.2 Network Non-Accessibility [%] 

This parameter was replaced by the "Network Selection and Registration Failure Ratio" and "Network Selection and 
Registration Time" parameter specified in clauses 5.2.1 and 5.2.2. 

5.2.1 {Manual | Automatic} Network Selection and Registration Failure 
Ratio [%] 

5.2.1 .1 Abstract Definition 

Probability that the user cannot perform a successful selection and registration on the desired PLMN (manual selection 
mode, automatic selection mode with a defined desired PLMN) or on some PLMN (automatic selection mode without a 
defined desired PLMN). 

Remarks: 

• The user equipment (UE) shall be deregistered from any available PLMN and shall not be within a registration 
procedure. 

• Some network (automatic selection mode) or the desired network (manual selection mode) to which the UE 
should register as well as the desired access technology shall be available and the UE shall be allowed to 
register to this network. 

• The UE shall support the +COPS conmiand set according to the definition in [21]: 

The optional <AcT> field of the +COPS set command as defined in [21] shall be supported by the UE, if 
used in the respective +COPS set conmiand. 

• The execution of the +COPS set command shall not be aborted by the sending of any other commands by the 
Terminal Equipment (TE). 

• The UE shall support the +CREG conmiand set according to the definition in [21]: 

The network registration unsolicited result code shall be enabled in the UE. 

• The UE shall support the +CGREG command set according to the definition in [21]: 

The GPRS network registration status unsolicited result code shall be enabled in the UE. 

• The MT shall be in full functionality state. 

5.2.1 .2 Abstract Equation 



{IVLanual I Automatic} Network Selection and Registration Failure Ratio [%] = 

unsuccessful selection and registration attemps on PLIVLN , 

xlOO 

all selection and registration attempts 
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5.2.1.3 Trigger Points 



Manual Network Selection and Registration - CS case: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Manual network selection and 
registration attempt 


Start: 

User initiates manual network 
selection and registration. 


Start: 

The set command "+C0PS=1 ,<format>,<oper> 
[,<AcT>]" for the +COPS command is sent. 


Successful manual network 
selection and registration 


Stop: 

Operator logo appears in the 
display of the UE. 


Stop: 

Reception of "OK" for the set command 

"+COPS=1,<format>,<oper>[,<AcT>]" 

and 

reception of the unsolicited result code for 
network registration status "+CREG" by IE with 
the value "1 " or "5" for <stat> 
and 

reception of the value "1 " for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 


Unsuccessful manual network 
selection and registration 


Stop trigger point not reached. 


Automatic network selection and registration - CS case: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Automatic network selection and 
registration attempt 


Start: 

User initiates automatic network 
selection and registration. 


Start: 

The set command "+COPS=0,0" for the +COPS 
command is sent. 


Successful automatic network 
selection and registration 


Stop: 

Operator logo appears in the 
display of the UE. 


Stop: 

Reception of "OK" for the set command 

"+COPS=0,0" 

and 

reception of the unsolicited result code for 
network registration status "+CREG" by the TE 
with the value "1" or "5" for <stat> 
and 

in addition and only in case a certain network 
operator is desired, 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 


Unsuccessful automatic network 
selection and registration 


Stop trigger point not reached. 
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Manual Network Selection and Registration - PS case: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Manual network selection and 
registration attempt 


Start: 

User initiates manual network 
selection and registration. 


Start: 

The set command "+C0PS=1 ,<format>,<oper> 
[,<AcT>]" for the +COPS command is sent. 


Successful manual network 
selection and registration 


Stop: 

PS logo appears in the display of 
the UE. 


Stop: 

Reception of "OK" for the set command 

"+COPS=1,<format>,<oper>[,<AcT>]" 

and 

reception of the unsolicited result code for 
GPRS network registration status "+CGREG" by 
TE with the value "1 " or "5" for <stat> 
and 

reception of the value "1 " for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 


Unsuccessful manual network 
selection and registration 


Stop trigger point not reached. 


Automatic network selection and registration - PS case: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Automatic network selection and 
registration attempt 


Start: 

User initiates automatic network 
selection and registration. 


Start: 

The set command "+COPS=0,0" for the +COPS 
command is sent. 


Successful automatic network 
selection and registration 


Stop: 

PS logo appears in the display of 
the UE. 


Stop: 

Reception of "OK" for the set command 

"+COPS=0,0" 

and 

reception of the unsolicited result code for 
GPRS network registration status "+CGREG" by 
the TE with the value "1" or "5" for <stat> 
and 

in addition and only in case a certain network 
operator is desired, 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 


Unsuccessful automatic network 
selection and registration 


Stop trigger point not reached. 



Some possible indicators for unsuccessful manual or automatic network selection and registration attempts are the 
following: 

• In case verbose <err> values have been enabled according to [21] via AT+CMEE=2: 
"+CMEERROR: <err>" is received for the +COPS set or read command. 

• No answer is received for the +COPS set or read command within a pre-determined time. 

• In case of manual network selection and registration: 

The desired value(s) from the +COPS set command for <oper>, and optionally for <AcT>, are not returned by 
the read conmiand. 

• No unsolicited result code for network registration status "+CREG" is received within a pre-determined time. 

• The unsolicited result code for network registration status "+CREG" is not received by the TE with the desired 
value "1" or "5" for <stat> within a pre-determined time. 

• No unsolicited result code for GPRS network registration status "+CGREG" is received within a pre- 
determined time. 
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• The unsolicited result code for GPRS network registration status "+CGREG" is not received by the TE with 
the desired value "1" or "5" for <stat> within a pre-determined time. 

5.2.2 {Manual | Automatic} Network Selection and Registration Time [s] 

5.2.2.1 Abstract Definition 

Time it takes the user to perform a successful selection and registration on the desired PLMN (manual selection mode, 
automatic selection mode with a defined desired PLMN) or on some PLMN (automatic selection mode without a 
defined desired PLMN). 

Remarks: 

• The user equipment (UE) shall be deregistered from any available PLMN and shall not be within a registration 
procedure. 

• Some network (automatic selection mode) or the desired network (manual selection mode) to which the UE 
should register as well as the desired access technology shall be available and the UE shall be allowed to 
register to this network. 

• The UE shall support the +COPS conmiand set according to the definition in [21]. 

• The optional <AcT> field of the +COPS set command as defined in [21] shall be supported by the UE, if used 
in the respective +COPS set conmiand. 

• The execution of the +COPS set command shall not be aborted by the sending of any other commands by the 
Terminal Equipment (TE). 

• The UE shall support the +CREG conmiand set according to the definition in [21]. 

• The network registration unsolicited result code shall be enabled in the UE. 

• The UE shall support the +CGREG command set according to the definition in [21]. 

• The GPRS network registration status unsolicited result code shall be enabled in the UE. 

• The MT shall be in full functionality state. 

5.2.2.2 Abstract Equation 



Network Selection and Registration Time [s] = 

( ^ start of network selection and registration attempt ^ successful network selection and registration 
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5.2.2.3 Trigger Points 



Manual Network Selection and Registration - CS case: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Start of network selection and 
registration attempt 


Start: 

User initiates manual network 
selection and registration. 


Start: 

The set command "+C0PS=1 ,<format>,<oper> 
[,<AcT>]" for the +COPS command is sent. 


Successful network selection and 
registration 


Stop: 

Operator logo appears in the 
display of the UE. 


Stop: 

The point in time where the unsolicited result 
code for network registration status "+CREG" is 
received by TE with the value "1 " or "5" for 
<stat> 
in case 

of the reception of "OK" for the set command 

"+COPS=1,<format>,<oper>[,<AcT>]" 

and 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 



Automatic network selection and registration - CS case: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Start of network selection and 
registration attempt 


Start: 

User initiates automatic network 
selection and registration. 


Start: 

The set command "+COPS=0,0" for the +COPS 
command is sent. 


Successful network selection and 
registration 


Stop: 

Operator logo appears in the 
display of the UE. 


Stop: 

The point in time where the unsolicited result 
code for network registration status "+CREG" is 
received by TE with the value "1 " or "5" for 
<stat> 
in case 

of the reception of "OK" for the set command 

"+COPS=0,0" 

and 

in addition and only in case a certain network 
operator is desired, 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 


Manual Network Selection and Registration - PS case: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Start of network selection and 
registration attempt 


Start: 

User initiates manual network 
selection and registration. 


Start: 

The set command "+COPS=1,<format>,<oper> 
[,<AcT>]" for the +COPS command is sent.. 


Successful network selection and 
registration 


Stop: 

PS logo appears in the display of 
the UE. 


Stop: 

The point in time where the unsolicited result 
code for GPRS network registration status 
"+CGREG" is received by TE with the value "1" 
or "5" for <stat> 
in case 

of the reception of "OK" for the set command 

"+COPS=1,<format>,<oper>[,<AcT>]" 

and 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 
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Automatic network selection and registration - PS case: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Start of network selection and 
registration attempt 


Start: 

User initiates automatic network 
selection and registration. 


Start: 

The set command "+COPS=0,0" for the +COPS 
command is sent. 


Successful network selection and 
registration 


Stop: 

PS logo appears in the display of 
the UE. 


Stop: 

The point in time where the unsolicited result 
code for GPRS network registration status 
"+CGREG" is received by TE with the value "1" 
or "5" for <stat> 
in case 

of the reception of "OK" for the set command 

"+COPS=0,0" 

and 

in addition and only in case a certain network 
operator is desired, 

reception of the value "0" for <mode> and the 
desired values for <oper>, and optionally 
<AcT>, for the read command "+COPS?". 



5.3 Attach Failure Ratio [%] 

5.3.1 Abstract Definition 

The attach failure ratio describes the probability that a subscriber cannot attach to the PS network. 

5.3.2 Abstract Equation 



, ^ . unsuccesslul attach attempts 

Attach Failure Ratio [%] = — x 100 

all attach attempts 



5.3.3 Trigger Points 

GPRS/UMTS: 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Attach attempt 


Start: User turns the UE on. 


Start: 

Layer 3 (GMM): The "ATTACH REQUEST" 
message is sent by the UE. 

AT: "AT+CGATT=1 " is sent by the TE. 


Successful attach attempt 


Stop: Attach logo appears in the 
display of the UE. 


Stop: 

Layer 3 (GMM): The "ATTACH ACCEPT" 
message is received by the UE. 

AT: "OK" is received by the TE. 


Unsuccessful attach attempt 


Stop trigger point not reached. 
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Remarks: 

• GPRS: Indicator will only be updated by event (a loss of SI 13 signalling or a coverage hole will not be 
detected if no attach, routing area update or TBF request is initiated). 

• It might occur that the UE sends more than one attach request towards the SGSN, since retries are necessary. 
A maximum of four retries are possible. 

These retries should not have impact on the attach failure ratio, since only one attach request message should 
be counted in the calculation. 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1). 

• The mobile shall be in detached state. "AT+CGATT?" may be used to check the attach state. 

5.4 Attach Setup Time [s] 

5.4.1 Abstract Definition 

The attach setup time describes the time period needed to attach to the PS network. 

5.4.2 Abstract Equation 

Attach Setup Time [s] = (t attach complete " ^ attach request 



5.4.3 Trigger Points 

GPRS/UMTS: 



Event from abstract equation 


Trigger point from user's point 
of view 


Teclinical description/protocol part 


Wach request: Time Of attach 

request 


Start: User turns the UE on. 


Start: 

Layer 3 (GMM): The "ATTACH REQUEST" 
message is sent by the UE. 

AT: "AT+CGATT=1 " is sent by the TE. 


Wachcompiete^Time when attach 
complete 


Stop: Attach logo appears in the 
display of the UE. 


Stop: 

Layer 3 (GMM): The "ATTACH ACCEPT" 
message is received by the UE. 

AT: "OK" is received by the TE. 



Remarks: 

• The difference between an attach request of a known subscriber and an unknown subscriber will be reflected 
in the time period indicating the attach setup time. In case of an unknown subscriber (meaning that the SGSN 
has changed since the last detach, or if it is the very first attach of the mobile to the network), the SGSN 
contacts the HLR in order to receive the subscriber data. The attach setup time of an unknown subscriber will 
be slightly longer than the one of a known subscriber. 

• While determining the average attach setup time only successful attach attempts are included in the 
calculations. 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1). 

• The mobile shall be in detached state. "AT+CGATT?" may be used to check the attach state. 
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5.5 PDP Context Activation Failure Ratio [%] 

5.5.1 Abstract Definition 

The PDP context activation failure ratio denotes the probabiHty that the PDP context cannot be activated. It is the 
proportion of unsuccessful PDP context activation attempts and the total number of PDP context activation attempts. 

5.5.2 Abstract Equation 



T^x^T^^ A . . X. t . r^n unsuccessful PDP context activation attempts 

PDP Context Activation Failure Ratio [%] = 100 

all PDP context activation attempts 



5.5.3 Trigger Points 

GPRS/UMTS: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PDP context activation attempt 


Start: User initiates the service 
access. 


Start: 

Layer 3 (SM): The first "ACTIVATE PDP 
CONTEXT REQUEST" message is sent by the 
UE. 

AT: "AT+CGACT=1 ,1 " is sent by the TE. 


PDP context activation attempt 


Stop: PDP context logo appears in 
the display of the UE. 


Stop: 

Layer 3 (GMM): The "ATTACH ACCEPT" 
message is received by the UE. 

AT: "OK" is received by the TE. 


Unsuccessful attempt 


Stop trigger point not reached. 



TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PDP context activation 
attempt 


Start: User initiates the 
service access. 


Start: 

Layer 3 (SNDCP): The first "SN-ACTIVATE PDP 
CONTEXT DEMAND" message is sent by the UE. 

AT: "ATD*99#" is sent by the TE. 


Successful PDP context 
activation attempt 


Stop: PDP context logo 
appears in the display of the 
UE. 


Stop: 

Layer 3 (SNDCP): The "SN-ACTIVATE PDP CONTEXT 
ACCEPT" message is received by the UE. 

AT: The "CONNECT" indication is received by the TE. 


Unsuccessful attempt 


Stop trigger point not reached. 
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Remarks: 

• In GPRS/UMTS the "AT+CGACT^l,!" shall be sent when the UE has no active context using the selected 
APN. "AT+CGACT?" may be used to check the state. The PDF context should be defined with the 
"AT+CGDCONT" command. 

• In GPRS/UMTS it might occur that the UE sends more than one PDP context activation request towards the 
SGSN since retries are necessary. A maximum of four retries are possible. The timer T3380 expires after 
30 seconds for each attempt, see TS 124 008 [10]. 

• In TETRA the "ATD*99#" shall be sent when the UE has no active context. The PDP context should be 
defined with the " AT+CTSDC" command. 

• In TETRA it might occur that the UE sends more than one PDP context activation request towards the SwMI, 
since retries are necessary. A maximum of RETRY_ACTIVATION = 3 retries are possible. 

• For GPRS/UMTS the PS bearer has to be active in the cell where the attempt is initiated (see clause 5.1) and 
the UE has to be attached (see clause 5.3). 

• For TETRA the PS services shall be enabled at the cell where the attempt is initiated. 

5.6 PDP Context Activation Time [s] 

5.6.1 Abstract Definition 

The PDP context activation time describes the time period needed for activating the PDP context. 

5.6.2 Abstract Equation 



PDP Context Activation Time [s] - (tp^p context activation accept " ^PDP context activation request /[^] 



5.6.3 Trigger Points 

GPRS/UMTS: 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Vdp context activation request " Time 

of PDP context activation request 


Start: User initiates tine service 
access. 


Start: 

Layer 3 (SM): The first "ACTIVATE PDP 
CONTEXT REQUEST" message is sent by the 
UE. 

AT: "AT+CGACT=1 ,1 " is sent by the TE. 


^PDP context activation accept " Time 
when PDP context activation 
complete 


Stop: PDP context logo appears in 
the display of the UE. 


Stop: Point of time when the UE receives the 
"Activate PDP context Accept" message 
(Layer 3). 
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TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^PDP context activation request " 
Time of PDP context 
activation request 


Start: User initiates the 
service access. 


Start: 

Layer 3 (SNDCP): The first "SN-ACTIVATE PDP 
CONTEXT DEMAND message is sent by the UE. 

AT: "ATD*99#" is sent by the TE. 


^PDP context activation accept " 
Time when PDP context 
activation complete 


Stop: PDP context logo 
appears in the display of the 
UE. 


Stop: 

Layer 3 (SNDCP): The "SN-ACTIVATE PDP CONTEXT 
ACCEPT" message is received by the UE. 

AT: The "CONNECT" indication is received by the TE. 



Remarks: 

• While determining the average PDP context activation time only successful activation attempts are included in 
the calculations (see clause 5.5). 

• The PDP context activation time should be determined per service, since the service might have impact on the 
actual activation time, e.g. different Access Point Names (APNs) for WAP. 



5.7 PDP Context Cut-off Ratio [%] 

5.7.1 Abstract Definition 

The PDP context cut-off ratio denotes the probability that a PDP context is deactivated without being initiated 
intentionally by the user. 

5.7.2 Abstract Equation 



PDP Context Cut - off Ratio [%] = 



PDP context losses not initiated by the user 
all successfully activated PDP contexts 



xlOO 



5.7.3 Trigger Points 

GPRS/UMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PDP context successfully 
activated 


Start: PDP context logo 
appears in the display of the 
UE. 


Start: 

Layer 3 (SM): The "ACTIVATE PDP CONTEXT ACCEPT" 
message is received by the UE. 


PDP context deactivation 
initiated by the user 


Stop: PDP context logo 
disappears from the display 
of theUE. 


Stop: 

Layer 3 (SM): The "DEACTIVATE PDP CONTEXT 
REQUEST" message is sent by the UE upon desired 
initiation. 


PDP context loss not 
initiated by the user 


Stop trigger point not reached. 
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TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PDP context successfully 
activated 


Start: PDP context logo 
appears in the display of the 
UE. 


Start: 

Layer 3 (SNDCP): The "SN-ACTIVATE PDP CONTEXT 
ACCEPT" message is received by the UE. 


PDP context deactivation 
initiated by the user 


Stop: PDP context logo 
disappears from the display 
of theUE. 


Stop: 

Layer 3 (SNDCP): The "SN-DEACTIVATE PDP CONTEXT 
DEMAND" message is sent by the UE upon desired 
initiation. 


PDP context loss not 
initiated by the user 


Stop trigger point not reached. 



Remarks: 

• Precondition for measuring this parameter is that a PDP context was successfully established first. 



Different trigger points for a PDP context deactivation not initiated intentionally by the user are possible: 
SGSN failure or GGSN failure on which the PDP context will be deactivated by the SGSN or GGSN. 



5.8 Data Call Access Failure Ratio [%] 



5.8.1 Abstract Definition 

A subscriber (A-party) wants to take advantage of a given service offering (as shown by the network ID in the display 
of his user equipment) and establish a data call to a B-party. The failure of the data call access from initiating the data 
call to alerting is covered by this parameter. 

5.8.2 Abstract Equation 



^ ^ 11 A ^ '^ • unsucccssful data Call acccsscs 

Data Call Access Failure Ratio [%] = x 1 00 

all data call access attempts 



5.8.3 Trigger Points 

GSM: 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Data call access attempt 


Start: CONNECT button is 
pressed. 


Start: 

Layer 3 (RR): The "CHANNEL REQUEST" 
message is sent over the RACH. 

AT: The "ATD <dial number>" (MSISDN) 
command is sent by the A-party. 


Successful data call access 


Stop: Alerting tone 
occurs/connection established. 


Stop: 

Layer 3 (CC): The "CONNECT" message is 
received by the A-party. 

AT: The "CONNECT" indication is received by 
the A-party. 


Unsuccessful data call access 


Stop trigger point not reached. 
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Remarks: 

• The " ATD <dial number>" (MSISDN) should be sent when there is no ongoing call. 

• " AT+CEER" can be used to read out the error cause. 

5.9 Data Call Access Time [s] 

5.9.1 Abstract Definition 

A subscriber (A-party) wants to take advantage of a given service offering (as shown by the network ID in the display 
of his user equipment) and establish a data call to a B -party. The time elapsing from initiating the data call to alerting or 
a busy signal is covered by this parameter. This parameter is not calculated unless the call attempt is successful and not 
cut off beforehand. 

5.9.2 Abstract Equation 



Data Call Access Time [S] - (t successful call access " ^initiation of data call ) [^] 



5.9.3 Trigger Points 

GSM: 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


^initiation of data call" 

initiation of data call 


Start: Time at which CONNECT 
button is pressed. 


Start: 

Layer 3 (RR): The "CHANNEL REQUEST" 
message is sent over the RACH. 

AT: The "ATD <dial number>" (MSISDN) 
command is sent by the A-party. 


^successful call access" Time Of 

successful data call access 


Stop: Time at which alert or busy 
signal occurs/connection 
established. 


Stop: 

Layer 3 (CC): The "CONNECT" message is 
received by the A-party. 

AT: The "CONNECT" indication is received by 
the A-party. 



Remarks: 

• The "ATD <dial number>" (MSISDN) should be sent when there is no ongoing call. 

• " AT-i-CEER" can be used to read out the error cause. 
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5.10 DNS Host Name Resolution Failure Ratio [%] 

5.10.1 Abstract Definition 

The DNS host name resolution failure ratio is the probability that a host name to host address translation of a DNS 
resolver was not successful. 

Remarks: 

• this QoS parameter is only relevant for packet switched services; 

• resolutions of different host names shall not be compared directly, since the time to perform a search in the 
DNS server differs depending on the host name; 

• resolutions involving different DNS name servers are not directly comparable; 

• resolutions utilizing TCP cannot be directly compared to resolutions using UDP, since messages carried by 
UDP are restricted to 512 bytes. UDP is the recommended method for standard queries on the Internet. 

5.10.2 Abstract Equation 



DNS Host Name Resolution Failure Ratio [%] = 

unsuccessM DNS host name resolution requests , 

xlOO 

DNS host name resolution requests 



5.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Host name resolution 
request 


Start: Request to resolve a 
host name. 


Start: Protocol: DNS. 

Data packet containing DNS type A (host address) "Standard 
query" message for the desired host name. 


Successful host name 
resolution request 


Stop: Host address resolved 
successfully. 


Stop: Protocol: DNS. 

Data packet received containing a type A (host address) 
"Standard query response, No error" response, the respective 
type A "Standard query" query and an answer including the 
desired host name to host address translation. 


Unsuccessful host name 
resolution request 


Stop: Host address not 
resolved. 


Stop trigger point not reached. 



Precondition for measurement: 

• The resolver shall not have direct access to any local DNS name server or any name server's zone. 

5.1 1 DNS Host Name Resolution Time [s] 
5.1 1 .1 Abstract Definition 

The DNS host name resolution time is the time it takes to perform a host name to host address translation. 



ETSI 



45 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



Remarks: 

• this QoS parameter is only relevant for packet switched services; 

• resolutions of different host names shall not be compared directly, since the time to perform a search in the 
DNS server differs depending on the host name; 

• resolutions involving different DNS name servers are not directly comparable; 

• resolutions utilizing TCP cannot be directly compared to resolutions using UDP, since messages carried by 
UDP are restricted to 512 bytes. UDP is the reconmiended method for standard queries on the Internet. 

5.11.2 Abstract Equation 



DNS Host Name Resolution Time [S] = (tstandardQueryResponse " tstandardQuery 



5.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


tstandardQuery: ^OSt name 

resolution request 


Start: Request to resolve a 
host address from DNS 
server. 


Start: Protocol: DNS. 

Data packet containing DNS type A (host address) 
"Standard query" query for the desired host name. 


TstandardQueryResponse: ^^^^ 

name resolution request 
answered 


Stop: Host address 
received from DNS server. 


Stop: Protocol: DNS. 

Data packet received containing a type A (host address) 
"Standard query response, No error" response, the 
respective type A "Standard query" query and an answer 
including the desired host name to host address translation. 



Precondition for measurement: 

• The resolver shall not have direct access to any local DNS name server or any name server's zone. 

• For static measurement methodologies, as defined in TS 102 250-3 [5], the queried DNS name server shall 
have any data related to the host name to be resolved available as authoritative data in one of the name server's 
zones, so that no recursive lookups have to be performed and no use of cached information will be required. 

• If the related data is not stored locally in the name server's zone, the resolution time would vary due to DNS 
caching strategies. 



6 Direct Services QoS Parameters 
6.1 File Transfer (FTP) 

6.1 .1 FTP {Download|Upload} Service Non-Accessibility [%] 
6.1 .1 .1 Abstract Definition 

The service accessibility ratio denotes the probability that a subscriber cannot estabhsh a PDP context and access the 
service successfully. 
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6.1 .1 .2 Abstract Equation 



FTP {Download I Upload} Service Non - Accessibility [%] = 

unsuccessful attempts to reach the point when content is sent or received , 

xlOO 

all attempts to reach the point when content is sent or received 



6.1.1.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's point 
of view 


Teclinical description/protocol part 


Service access attempt 


Start: User initiates the service 
access. 


Start: AID command. 


Successful attempt 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 


Upload: 


Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Service access attempt 


Start: User initiates the service 
access. 


Start: AID command. 


Successful attempt 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 .2 FTP {Download|Upload} Setup Time [s] 

6.1.2.1 Abstract Definition 

The setup time describes the time period needed to access the service successfully, from starting the dial-up connection 
to the point of time when the content is sent or received. 

6.1.2.2 Abstract Equation 



FTP {Download I Upload} Setup Time [s] = (t,ervice access successful " tsemce access start )[s] 
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6.1.2.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


^service access start: Time of service 

access attempt 


Start: User initiates the service 
access. 


Start: ATD command. 


^service access successful' "'"'me of 

successful service access 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop IVIethod B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Upload: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^service access start^ Time of Service 
access attempt 


Start: User initiates the service 
access. 


Start: ATD command. 


^service access successful' Time Of 

successful service access 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 .3 FTP {Download|Upload} IP-Service Access Failure Ratio [%] 

6.1 .3.1 Abstract Definition 

The IP-service access ratio denotes the probability that a subscriber cannot establish a TCP/IP connection to the server 
of a service successfully. 

6.1.3.2 Abstract Equation 



FTP {Download I Upload} IP - Service Access Failure Ratio [%] = 

unsuccessful attempts to establish an IP connection to the server 
all attempts to establish an IP connection to the server 



xlOO 
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6.1.3.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


IP-Service access attempt 


Start: User initiates file download. 


Start: First [SYN] sent on the data socket. 


Successful attempt 


Stop: File download starts. 


Stop IVIethod A: Reception of the first data 
packet containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 


Upload: 


Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


IP-Service access attempt 


Start: User initiates file upload. 


Start: First [SYN] sent on the data socket. 


Successful attempt 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .4 FTP {Download|Upload} IP-Service Setup Time [s] 

6.1.4.1 Abstract Definition 

The IP-service setup time is the time period needed to estabhsh a TCP/IP connection to the server of a service, from 
sending the initial query to a server to the point of time when the content is sent or received. 

6.1.4.2 Abstract Equation 



FTP {Download I Upload} IP -Service Setup Time [S] = (tip.serviceaccesssuccessful " tlp.Serviceaccessstart)[s] 
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6.1.4.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's point 
of view 


Teclinical description/protocol part 


W-Service access start" "'"''^^ 

IP-Service access attempt 


Start: User initiates file download. 


Start: First [SYN] sent. 


^IP-Service access successful' "'"''^^ 

successful IP-Service access 


Stop: File download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Upload: 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


V-Service access start" "l"'"^® 

IP-Service access attempt 


Start: User initiates file upload. 


Start: First [SYN] sent. 


W-Service access successful" Time Of 

successful IP-Service access 


Stop: File upload starts. 


Stop Method A: Sending of the first data packet 
containing content. 

Stop Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 



Remark: 



• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.1 .5 FTP {Download|Upload} Session Failure Ratio [%] 
6.1 .5.1 Abstract Definition 

The session failure ratio is the proportion of uncompleted sessions and sessions that were started successfully. 



6.1.5.2 Abstract Equation 



FTP {Download I Upload} Session Failure Ratio [%] = 



uncompleted sessions 
successfully started sessions 



-xlOO 



6.1.5.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started session 


Start: User initiates file download. 


Start: First [SYN] sent on the control socket. 


Completed session 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Uncompleted session 


Stop trigger point not reached. 
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Upload: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started session 


Start: User initiates file upload. 


Start: First [SYN] sent on the control socket. 


Completed session 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 


Uncompleted session 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .6 FTP {Download|Upload} Session Time [s] 

6.1.6.1 Abstract Definition 

The session time is the time period needed to successfully complete a PS data session. 

6.1.6.2 Abstract Equation 

FTP {Download I Upload} Session Time [s] = (t,,,,i„„,„d " tsession start 



6.1.6.3 Trigger Points 

Download: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^session start^ ^ime of Successfully 
started session 


Start: User initiates file download. 


Start: First [SYN] sent on the control socket. 


^session end: Time when session 
completed 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Upload: 


Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


^session start: Time of Successfully 
started session 


Start: User initiates file upload. 


Start: First [SYN] sent on the control socket. 


^session end^ Time when session 
completed 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 .7 FTP {Download|Upload} Mean Data Rate [kbit/s] 
6.1 .7.1 Abstract Definition 

After a data link has been successfully established, this parameter describes the average data transfer rate measured 
throughout the entire connect time to the service. The data transfer shall be successfully terminated. The prerequisite for 
this parameter is network and service access. 
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6.1 .7.2 Abstract Equation 



FTP { Download I Upload } Mean Data Rate [kbit/s] 



user data transferred [kbit] 

(^data transfer complete ~ ^data transfer start ) [^] 



6.1.7.3 Trigger Points 

The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (file). 

Download: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^data transfer start ■ "'"''^^ 

successfully started data transfer 


Start: File download starts. 


Start IVIethod A: Reception of the first data 
packet containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


^data transfer complete" "^^^^ 

data transfer complete 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Upload: 


Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^data transfer start ■ "'"''^^ 

successfully started data transfer 


Start: File upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections; 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Wta transfer complete^ ^ime when 

data transfer complete 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

6.1 .8 FTP {DownloadjUpload} Data Transfer Cut-off Ratio [%] 
6.1.8.1 Abstract Definition 

The data transfer cut-off ratio is the proportion of incomplete data transfers and data transfers that were started 
successfully. 



6.1.8.2 Abstract Equation 



FTP {Download I Upload} Data Transfer Cut - off Ratio [%] = 
incomplete data transfers 



successfully started data transfers 
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6.1.8.3 Trigger Points 

Download: 



Event from abstract enuation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: File download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Complete data transfer 


Stop: File download successfully 
completed. 


Stop: Reception of the last data packet 
containing content. 


Incomplete data transfer 


Stop trigger point not reached. 


Upload: 


Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: File upload starts. 


Start Method A: Sending of the first data packet 
containing content. 

Start Method B: Reception of the [ACK] from the 
[SYN, ACK] for active mode connections, 
sending of the [ACK] for the [SYN, ACK] for 
passive mode connections on the data socket. 


Complete data transfer 


Stop: File upload successfully 
completed. 


Stop: Reception of the [FIN, ACK] for the last 
data packet containing content. 


Incomplete data transfer 


Stop trigger point not reached. 



Remark: 

• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 

6.2 Mobile Broadcast 

Mobile Broadcast is an end-to-end broadcast system for delivery of any types of digital content and services using 
IP-based mechanisms. An inherent part of the Mobile Broadcast system is that it comprises of a unidirectional broadcast 
path (e.g. DVB-H, MBMS, and other broadcast bearers) and a bidirectional mobile/cellular interactivity path 
(e.g. GSM, GPRS, UMTS). The Mobile Broadcast Service is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. 

Figure 4 depicts the basis for a generic service concept for mobile broadcast. As being a composite service, two 
different bearers may be involved in mobile broadcast services. Unidirectional broadcast information is transmitted over 
the broadcast channel, whereas interactive procedures are related to the interactivity channel provided by a mobile 
network. The independent procedures at both bearers may interact with each other and build a common end-to-end 
procedure. 

In general, this concept is not dedicated to specific bearer technologies. Different bearer technologies and their 
combinations are thinkable of. 

Remarks: 

• However, the concept depends for example on the implementation of the Electronic Service Guide (ESG). If 
the ESG implementation does not allow the user to recognize the reception of ESG information, the according 
parameters shall have to be adapted. 

• Content encryption may be a central element of DVB-H implementations. This issue is not dealt with 
explicitly in what follows and needs further consideration. 
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Figure 4: Service pliases of mobile broadcast 



From a user's point of view, the usage cycle of mobile broadcast services can be divided into: 

• Terminal registration Local service activation: The broadcast receiver is switched on and the terminal registers 
to the broadcast bearer. This procedure includes the detection of a broadcast service signal. 

• Bootstrapping: During this phase, the detected broadcast signal is decoded. At the end of this phase, a list of 
receivables channels is available. Each channel offers additional information via its own Electronic Service 
Guide (ESG). 

• ESG Retrieval: At this stage, the information where to find ESG information is available. After a channel is 
selected, the channel related information is received, decoded and presented to the user. For example, an 
overview over the current and following programs can be shown on the display. The ESG information itself 
can be retrieved either via the broadcast bearer or via the interactivity service, for example via a WAP portal. 

• Service discovery: This phase includes the bootstrapping phase and the ESG retrieval phase. Please note that 
manual channel selection may lead to an additional delay between both phases. During this phase, the detected 
broadcast signal is decoded. Afterwards, the information where to find Electronic Service Guide (ESG) 
information is available. The ESG information itself can be retrieved either via the broadcast bearer or via the 
interactivity service, for example via a WAP portal. 

• Content reception: The generic term "content" comprises all kinds of content that can be transferred via the 
broadcast service. Examples for this kind of data are audio and video streams, file downloads and related 
metadata which describes the carried content. 

• Interactivity based procedures: These procedures allow the interactive use of the mobile broadcast service. In 
general, all transmission capabilities offered by the mobile network can be used for this issue. Examples are: 

content requests via a WAP GET request; 

SMS voting; 

request to receive ESG information via MMS service; or 

voice control to request a dedicated file via the broadcast service. 
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The technical interpretation of this generic usage cycle leads to the phases: 
Mobile Broadcast Network Non- Accessibility. 
Mobile Broadcast Program Menu Non- Accessibility. 
Mobile Broadcast Channel Non- Accessibility. 
Mobile Broadcast Interactivity Response. 
Mobile Broadcast Session Cut Off Ratio. 
Mobile Broadcast Service Integrity. 
The mentioned phases are covered by the parameters described subsequently. 

6.2.1 Mobile Broadcast Network Non-Availability {Broadcast Bearer} 

6.2.1 .1 Abstract Definition 

Probability that the Mobile Broadcast Services are not offered to an end-user by the target network indicators on the 
User Equipment (UE) in idle mode. 

6.2.1.2 Abstract Equation 



Mobile Broadcast Network Non - Accessibility [%] = 

unsuccessful Mobile Broadcast registration attempts 
all Mobile Broadcast registration attempts 



xlOO 



6.2.1.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Mobile Broadcast registration 
attempt 


Start: Start of registration 
procedure performed by the UE. 


Tbd. 


Unsuccessful Mobile Broadcast 
registration attempt 


Stop: "Mobile Broadcast icon", 
which indicates successfully 
registration, is not displayed on the 
UE. 


Tbd. 



Preconditions for measurement: 

• The terminal shall be in an area which is intended to be covered by the broadcast service. 

• The receiver responsible for the reception of Mobile Broadcast services shall be activated and initialized. 

6.2.2 Mobile Broadcast Program Menu Non-Accessibility {Bootstrapping 
Bearer, ESG Retrieval Bearer} 

6.2.2.1 Abstract Definition 

This parameter describes the probability that the Mobile Broadcast Program Menu is successfully accessible by the user 
when requested. 

Remark: 

• This parameter depends on the actual implementation of the service discovery procedures (e.g. use of cached 
bootstrapping and/or ESG information). 
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6.2.2.2 Abstract Equation 



Mobile Broadcast Program Menu Non - Accessibility [%] = 



unsuccessfiil program menu access attempts 
all program menu access attempts 



xlOO 



6.2.2.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Mobile Broadcast Program Menu 
access attempt 


Start: Request to use the Mobile 
Broadcast service on the 
UE (push on TV button). 


Start: Tbd. 


Unsuccessful Mobile Broadcast 
Program Menu access attempt 


Stop: Mobile Broadcast service is 
not available on the UE (no TV 
channel list displayed). 


Stop: Tbd. 



Preconditions for measurement: 



• Mobile Broadcast Network Availability must be given. 



6.2.3 Mobile Broadcast Program Menu Access Time {Bootstrapping 
Bearer, ESG Retrieval Bearer} 

6.2.3.1 Abstract Definition 

The parameter Mobile Broadcast Program Menu Access Time is the time period elapsed between a session start attempt 
of the Mobile Broadcast service and the reception of the complete menu channels list. Hereby, the time the device 
requires to discover the available channels for the first time is considered. 



6.2.3.2 Abstract Equation 

Mobile Broadcast Program Menu Access Time [s] = (tp„g,^ ,^,p^„„ - tp,„g,,^ )[s] 



6.2.3.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


program menu request: "'"''^^ 

Mobile Broadcast Program Menu 


Start: First request of the Mobile 
Broadcast service on the 
UE. 


Start: Tbd. 


program menu reception: "'"''^^ 0^ 

successful Mobile Broadcast 
Program Menu reception 


Stop: Mobile Broadcast channel list 
is given within a pre-determined 
time. 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 
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6.2.4 Mobile Broadcast Channel Non-Accessibility {Broadcast Bearer} 

6.2.4.1 Abstract Definition 

Probability that the requested Mobile Broadcast channel is not started to be delivered to the user. This parameter applies 
also to zapping situations in which the user changes the offered streaming content frequently in short intervals. 

6.2.4.2 Abstract Equation 



Mobile Broadcast Channel Non - Accessibility [%] = 
unsuccessful channel access attempts 



all channel attempts 



-xlOO 



6.2.4.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Channel Access attempt 


Start: Request Channel button 
pressed by user/request attempt 
from device. 


Start: Tbd. 


Unsuccessful Channel Access 
attempt 


Stop: Missing indication of 
reception of channel content 
(channel displayed). 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

6.2.5 Mobile Broadcast Channel Access Time {Broadcast Bearer} 

6.2.5.1 Abstract Definition 

The parameter Mobile Broadcast Channel Access Time is the time period elapsed between the user's request to access 
the channel and the Channel reception/displayed. 

6.2.5.2 Abstract Equation 



Mobile Broadcast Channel Access Time [s] = (t,har,„ei reception "tchannei request 



6.2.5.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


^channel request: Channel request 
time 


Start: Request channel button 
pressed by user. 


Start: Tbd. 


^channel reception: Channel 

reception time 


Stop: reception of channel content 
(channel displayed). 


Stop: Tbd. 
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Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

6.2.6 Mobile Broadcast Interactivity Response Failure Ratio {Mobile 
Network Bearer} {Broadcast Bearer} 

6.2.6.1 Abstract Definition 

The Mobile Broadcast Interactivity Response Failure Ratio measures the probability that a service request of a Mobile 
Broadcast service via an interactive channel does not result in an expected reaction (i.e. changes in content updated due 
to user's interaction, reception of any kind of notification to the user, etc.) on either the broadcast bearer or the mobile 
network bearer. 



6.2.6.2 Abstract Equation 



Mobile Broadcast Interactivity Response Failure Ratio [%] = 

unsuccessful Mobile Broadcast service outcomes/repsonses 
all Mobile Broadcast service requests over interactive channel 



xlOO 



6.2.6.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Mobile Broadcast service request 
over interactive channel 


Start: Request of the Mobile 
Broadcast service on the 
UE. 


Start: Tbd. 

Content Request on Interactivity Channel: 
Trigger points are chosen according to 
parameter definitions for SMS, MMS, GPRS 
and PS-UMTS in the present document. 


Unsuccessful Mobile Broadcast 
service outcome/response 


Stop: User's interactivity is not 
reflected in updated content or 
indicated at the device. 


Stop: Tbd. 

Negative result code or timeout related to 
Interactivity Channel: Trigger points are chosen 
according to parameter definitions for SMS, 
MMS, GPRS and PS-UMTS in the present 
document. 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 
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6.2.7 Mobile Broadcast Interactivity Response Time {Mobile Network 
Bearer} {Broadcast Bearer} 

6.2.7.1 Abstract Definition 

The parameter Mobile Broadcast Interactivity Response Time is the time elapsed between a service request attempt of 
the Mobile Broadcast service via an interactive channel and the reception of a notification to the user. 



6.2.7.2 Abstract Equation 



Mobile Broadcast Interactivity Response Time [s] = (t,ervicerepsonse " tservice request )[s] 



6.2.7.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


^service request: Mobile Broadcast 
service request over interactive 
channel 


Start: Request of the Mobile 
Broadcast service on the 
UE. 


Start: Tbd. 

Content Request on Interactivity Channel: 
Trigger points are chosen according to 
parameter definitions for SMS, MMS, GPRS 
and PS-UMTS in the present document. 


tserviceresponce: SuCCOSSful Mobile 

Broadcast service 
outcome/response 


Stop: User's interactivity is not 
reflected in updated content or 
indicated at the device. 


Stop: Tbd. 

Negative result code or timeout related to 
Interactivity Channel: Trigger points are chosen 
according to parameter definitions for SMS, 
MMS, GPRS and PS-UMTS in the present 
document. 



Preconditions for measurement: 

• For broadcast bearer: 

Mobile Broadcast Network Availability must be given. 

• For mobile network bearer: 

Mobile Network Availability must be given. 

Mobile Network Service Accessibility for circuit switched or packet switched data services must be 
given. 

6.2.8 Mobile Broadcast Session Cut-off Ratio {Broadcast Bearer} 
6.2.8.1 Abstract Definition 

Session Cut Off denotes the probability of abnormal termination of the specific service requested by the user. 



6.2.8.2 Abstract Equation 



Mobile Broadcast Session Cut - off Ratio [%] = 



unsuccessfully terminated sessions 
all successfully established sessions 



xlOO 
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6.2.8.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Successfully established 
sessions 


Start: Channel reproduction 
started. 


Start: Tbd. 


Unsuccessfully terminated 
sessions 


Stop: Channel reproduction 
terminated abnormally (exit from 
service). 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

• Mobile Broadcast Channel Accessibility must be successful. 

6.2.9 Mobile Broadcast Service Integrity {Broadcast Bearer} 

Mobile Broadcast technology paves the way for network operators and service providers to offer a huge palette of 
mobile services, which can be divided in the following categories: 

Streaming services. 

Packet switched data services. 

Short Message Service (SMS). 

Multimedia Message Service (MMS). 

Wireless Application Protocol (WAP). 

Digital Video Broadcasting - Handheld (DVB-H). 

According to ITU-T Reconmiendation E.800 [20], the Service Integrity describes the Quality of Service during service 
use. Since the above mentioned services are already offered in other scenarios, in the present document only a reference 
to the already defined QoS parameters will be made. Important to bear in mind is the fact that for Mobile Broadcast 
Service, only the abstract definition of the parameters applies, since the underlying protocol stack may not be the same. 

6.2.10 Mobile Broadcast Reproduction Soft Cut-off Ratio {Broadcast 
Bearer} 

6.2.1 0.1 Abstract Definition 

Reproduction Soft Cut Off denotes the probability that the end-user cannot see normally the channel when connected to 
the specific service. 



6.2.1 0.2 Abstract Equation 



Mobile Broadcast Reproduction Soft Cut - off Ratio [%] = 



^ 1 fluid audio/video restart ~ ^ signal weak ) 
^reproduction finished ~ ^ reproduction started 



xlOO 
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6.2.10.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


^signal weak 


Start: Channel displays e.g. blue 
screen "TV signal weak search of 
the signal in progress". 


Start: Tbd. 


^fluid audio/video restart 


Stop: The service restarts 
normally. 


Stop: Tbd. 


Reproduction started 


Start: Begin of reproduction. 


Start: Tbd. 


Reproduction finished 


Stop: End of reproduction. 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

• Mobile Broadcast Channel Accessibility must be successful. 

6.2.1 1 Mobile Broadcast Reproduction Hard Cut-off Ratio {Broadcast 
Bearer} 

6.2.1 1 .1 Abstract Definition 

Reproduction Hard Cut Off denotes that the end-user cannot see normally the channel when connected to the specific 
service. 



6.2.1 1 .2 Abstract Equation 



Mobile Broadcast Reproduction Hard Cut - off Ratio [%] = 

^ ! Fluid audio/video restart ~ ^ signal absent ) 



^ reproduction finished ~ ^ reproduction started 



xlOO 



6.2.11.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


^signal absent 


Start: Channel displays e.g. blue 
screen "TV signal absent tuning in 
progress". 


Start: Tbd. 


^fluid audio/video restart 


Stop: The service restarts 
normally. 


Stop: Tbd. 


Reproduction started 


Start: Begin of reproduction. 


Start: Tbd. 


Reproduction finished 


Stop: End of reproduction. 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

• Mobile Broadcast Channel Accessibility must be successful. 
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6.2.12 Mobile Broadcast Audio Quality {Broadcast Bearer} 
6.2.12.1 Abstract Definition 

Mobile Broadcast Audio Quality describes the audio quality as perceived by the end-user. Since the streams can contain 
but not only speech information, an algorithm like ITU Recommendation P. 862 [1] is not suitable for all scenarios and 
should not be used. 

An audio algorithm, such as ITU-T Reconmiendation P. 862 [1] may be used. 



6.2.1 2.2 Abstract Equation 

Tbd. 

6.2.12.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Tbd. 


Start: Begin of audio reproduction. 


Start: Tbd. 


Tbd. 


Stop: End of audio reproduction. 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

• Mobile Broadcast Channel Accessibility must be successful. 

6.2.13 Mobile Broadcast Video Quality {Broadcast Bearer} 
6.2.13.1 Abstract Definition 

Mobile Broadcast Video Quality describes the video quality as perceived by the end-user. 



6.2.13.2 Abstract Equation 

Tbd. 

6.2.13.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Tbd. 


Start: Begin of video reproduction. 


Start: Tbd. 


Tbd. 


Stop: End of video reproduction. 


Stop: Tbd. 



Preconditions for measurement: 

• Mobile Broadcast Network Availability must be given. 

• Mobile Broadcast Program Menu Accessibility must be successful. 

• Mobile Broadcast Channel Accessibility must be successful. 

For wireless application protocol services, a reference from the Open Mobile Alliance (OMA) should be added (if 
available). 
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6.3 Ping 

6.3.1 Ping Round Trip Time [ms] 

6.3.1.1 Abstract Definition 

The round trip time is the time required for a packet to travel from a source to a destination and back. It is used to 
measure the delay on a network at a given time. For this measurement the service must already be established. 

6.3.1.2 Abstract Equation 



Ping Round Trip Time [ms] = (tp,,ke, received " tpacketsem )[ms] 



6.3.1.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Wketsent^ Time when packet is 
sent 


Start: User starts Ping client. 


Start: ICMP echo request sent. 


jacket received^ Time when packet 
is received 


Stop: Echo reply is displayed. 


Stop: ICMP echo reply received by the sender. 



As an alternative the measurement of the round trip time can done by evaluating the TCP handshake: 

• Start: Point of time when the [SYN] is sent. 

• Stop: Point of time when the [SYN, ACK] is received. 

This applies to all services that are TCP based, e.g. file transfer (FTP), web browsing (HTTP) and E-Mail (POPS, 
SMTP). 

6.4 Push to Talk over Cellular (PoC) 

The present clause describes QoS parameters for the Push to Talk over Cellular (PoC) service as described in [14], [15], 
[16] and [17]. 

To point out the development and effectiveness of these QoS parameters, a generic PoC signal flow is given. Here, 
some restricted information on the application layer is given. These events only show important user interactions. In this 
context it is important to point out that the present document does not focus on the application layer or the user plane as 
described in [15]. 

The SDP is not mentioned as an alternative to RTP in [14], [15] and [16]. Thus, trigger points defined on the SDP layer 
are out of scope of the present document. 

NOTE: All Quality of Service parameters defined for the PoC service which do not rely on RTP in terms of 
trigger point definition are to be applied when measuring a PoC service utilizing SRTP. 

Furthermore, some typical PoC signal flows are given in an informative annex together with some signal grouping. 
Here, signals have been grouped together in order the give a better insight into the signal flow details and their relation 
to some specific group of PoC QoS parameters. 

The Push to Talk over Cellular (PoC) service is characterized by a half duplex form of communication, whereby one 
end-user will communicate with other end-users by pressing a button, or an equivalent function, on a terminal. In the 
following text it will be assumed without loss of generality that the terminal has a PoC button. 

It is important to keep in mind that measurement equipment and techniques used can affect the data collected. The 
measurement equipment and techniques should be defined and their effects documented for all tests. 
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Remarks: 

• All end trigger points defined in the present document will occur after the appropriate start trigger points. The 
message flow between each two trigger points is described in the text or there is a reference to a figure that 
visualizes the message flow. 

• All SIP and RTP messages that are sent during a PoC session utilize UDP as transport layer. 

• If a trigger point (technical description/protocol part) in the present document states: "First data packet sent. . . " 
then the time stamp shall be the point in time when the message is posted to the UDP transport layer. 

• If a trigger point (technical description/protocol part) in the present document states: "First data packet 
received. . . " then the time stamp shall be the point in time when the message is received on the UDP transport 
layer. 

• Trigger points for failure ratios (technical description/protocol part) may state: "No message received by the 
terminal within a pre-determined time", which means that the PoC server timed out. Here, the exact timeout 
has to be specified. 

• If the present document states: "active PoC talk session", then a PoC session with at least two joining parties is 
meant, regardless of the kind of session (1-1, ad-hoc group talk, pre-arranged group talk or chat). Furthermore, 
one of the participating terminals shall create and send data packets containing speech data (RTP media 
stream). 

• Unless explicitly stated differently, all terminals participating in PoC sessions shall not generate notification 
messages. Otherwise, "SIP NOTIFY" messages might get sent to these clients leading to possible impacts on 
the measurement results. 



6.4.1 Definitions 

For PoC, there are differences between on-demand and pre-established PoC sessions which need to be taken into 
account. Thus, a direct comparison between these session types shall be avoided. 

Another difference to be aware of is the form of indication used. If confirmed indication is used, the initiator has to wait 
for the "talk burst granted" indication until at least one invited user has accepted the invitation. If unconfirmed 
indication is used, at least one invited user has to be registered and uses automatic answer. This results in different 
message flows as well as in different response times (especially if media buffering is supported by the PoC server). 

Particularities occur when using a pre-arranged PoC group session. In this kind of session the initiator invites a group of 
users. With confirmed indication at least one user has to accept the invitation but with unconfirmed indication the 
right-to-speak is granted at once; regardless if a user of the group is connected to the PoC service or not. 

Table 1 gives an overview of the defined QoS parameters. Groups of parameters are introduced to visualize 
interdependencies. The reason is that certain measurements can only take place if several preconditions are fulfilled. 
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Table 1 : QoS parameter and required preconditions 



QoS Group 




On^ nflmmptpr in thiQ nrniin 


t 1 d#\^l lUlllwl 19 


REG 


PnO Ronictratinn 
rUw ric^y loll clUUI 1 


O.H-.O, O.H-.H- 




PUB 




Pt A ^ fi 4 fi 


REG 

ri 1 — \j 


REG long 


PnP. RpniQtrfltinn -i- PnP. PiihliQh 


R4fi'^ ^47^^ 
u.*+.u.o, u.*+./.o 




On 

demand 


INIT 


PnP .^PQQinn Initiation 


yj ."-r .KJ .\j ,\J ."-r .\j 


PUB 


SETUP 


PnP Qpccinn Qoti in 

rUO OCOOlUI 1 OC7lU|J 


R414'^ R417 




PtS 


Pi ich tn Qnponh 

rUoll lU 0|JC7C7UI 1 


R41R R41Q 


PI IR 


LEAVE 


PnP ^PQQinn 1 pa\/inn 
ocooi^i 1 1— ccivii 1^ 


R 4 pn R 4 P1 


INIT nr SETUP 

IIMI 1 \Jl 1 1 \Ji 


Pre-establish 
ed 


NEGO 


PnP ^yloHia Paramptprc Monntiatinn 

rUO IVICUlCl rcUdlllCldO INCyULIClLIUI I 


R4in'^ R411 


PI IR 


INIT 


PnP Qpccinn Initiatinn 
ruo ocooiui 1 II iiiiciiivji 1 


R41P'^ R414 




SETUP 


PnP f^p^^inn f^ptiin 


R 4 16 R 4 17 




PtS 


Push to Speech 


6.4.18, 6.4.19 


PUB 


LEAVE 


PoC Session Leaving 


6.4.22, 6.4.23 


INIT or SETUP 


DeREG 


PoC Deregistration 


6.4.24, 6.4.25 


REG or SETUP 


BUSY 


Busy Floor Response 


6.4.26, 6.4.27 


SETUP or PtS 


REQ 


Talk Burst Request 


6.4.28, 6.4.29 


SETUP or PtS 


CUT 


PoC Session Cut-off 


6.4.30 


SETUP or PtS 


DROP 


Talk Burst Drop 


6.4.31 


SETUP or PtS 


DELAY 


Talk Burst Delay 


6.4.32, 6.4.33 


SETUO or PtS 



6.4.2 Generic Signal Flow 

This clause gives an overview of some signal flows evolving from PoC sessions. In Figure 5, a generic signal flow is 
given. Here, the main parts of a PoC session, also including the registration of the PoC service, are visualized. These 
are: PoC service registration (including PoC service settings publishment), PoC session initiation, PoC talk session, PoC 
session leaving and finally the PoC service deregistration. 

Most of the PoC relevant (application layer-) events generated from or receivable by the user are included in this 
Figure. These events are represented as dashed lines. 

In the present document greyed lines are optional signals which do not have to be send (like the "SIP NOTIFY" 
message which will only be sent by the PoC server if the "norefersub" option tag was included in the "SIP REFER" 
request (see [16])). Provisional SIP responses as described in [6] (e.g. "SIP 100 Trying") are greyed for clarity. These 
messages are provisional responses and shall be turned off during measurements. 
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A generic PoC session: 
' • ' PoC Registration. 
^^^B PoC Session Initiation. 
^^^H PoC Talk Session. 
I^H^^ Leaving PoC Session. 
^^^^ PoC Deregistration. 



Terminal A 



User A PoC Service 
Registration 

< 

"PoC active" indicated 



Talk Burst Request 
(Pushing PoC button) 



PoC Network 



Registration 



Talk Burst Granted 

Indicator 
< 




Terminal B 



User B PoC Service 
Registration 



Registration 



ession Initiatio 



Start of speech 



PoC 
Session 



^nd of speech 



1 — T 



Media Stream from User A 



"PoC active" indicated 



User B accepts incoming 
PoC session 



End of speech 



Talk Burst Request 
(Pushing PoC button) 



. ongoing PoC Talk Session ... 



Media Stream from User B 



User A Service 
Deregistration 



Leaving the PoC Session 



Start of speech 



User B Service 
Deregistration 



Leaving the PoC Session 



"PoC inactive" 
indicated 



Deregistration 



"PoC inactive" indicated 



NOTE: Here, the dashed arrows indicate events generated from or receivable by the user. 

Figure 5: Generic PoC session signal flow 
(including PoC service registration) on application layer 



6.4.3 PoC Registration Failure Ratio [%] 



6.4.3.1 Abstract Definition 

The PoC registration failure ratio is the probability that the terminal cannot register with the Push to Talk over Cellular 
service when requested. 

Remark: 

• The terminal shall not be registered to the PoC service. 
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6.4.3.2 Abstract Equation 



^ . . ^ . unsuccessful PoC registration attempts 

PoC Registration Failure Ratio [%] = ^ *^xlOO 

all PoC registration attempts 



Terminal SIP Core 




SIP REGISTER ^ 




SIP 401 Unauthorized 


< 

SIP REGISTER ^ 


^ SIP 403 Forbidden 





NOTE: This Figure shows an example for an unsuccessful PoC registration. After the first "SIP REGISTER" 

request the terminal has to answer to a WWW- authentication challenge (see [16]). If the terminal does not 
answer correctly to this challenge, the SIP core will send a "SIP 403 Forbidden" message. 

Figure 6: Unsuccessful PoC registration example 



6.4.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC registration attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC 
registration attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" 
message. 


Unsuccessful PoC 
registration attempt 


Stop: PoC available 
indication is not given within 
a pre-determined time. 


Stop: Protocol: SIP. 

Case 1 : Second data packet received by the terminal (after 
sending the "SIP REGISTER" message) containing a 
message different to "SIP 200 OK". This message may be 
implementation-dependent (see [16]). 

Case 2: First data packet received by the terminal (after the 
authentication procedure) containing a message different to 
"SIP 200 OK". 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.4 PoC Registration Time [s] 
6.4.4.1 Abstract Definition 

The PoC registration time is the time period between the registration request of the PoC service and being registered to 
the PoC service. 

Remark: 

• The terminal shall not be registered to the PoC service. 
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6.4.4.2 Abstract Equation 



PoC Registration Time [s] — (tpQ(.^^^ji^|^ig - tpQCA^^tj^atg^j )[s] 



Terminal SIP Core 




SIP REGISTER ^ 




SIP 401 Unauthorized 


SIP REGISTER ^ 


^ SIP 200 OK 





NOTE: This Figure shows an example of a successful PoC registration (see [16]). In contrast to Figure 11 , the 
terminal answered correctly to the authentication challenge (the second "SIP REGISTER" message). 

Figure 7: Successful PoC registration example 

6.4.4.3 Trigger Points 



Event from 
abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


VoC Activated: "'"''^^ 

PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP REGISTER" 
message. 


VoCAvailable: ^ime Of 

successful PoC 
registration attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 



6.4.5 PoC Publish Failure Ratio [%] 
6.4.5.1 Abstract Definition 

The PoC publish failure ratio is the probability that the terminal cannot successfully publish his PoC service settings to 
the PoC server, after the terminal is registered to the PoC service. 

Remarks: 

• To set, update or refresh the PoC service settings, the terminal generates a "SIP PUBLISH" request with XML 
MIME content according to rules and procedures of [17]. 

• The terminal shall be registered to the PoC service. 

• PoC enabled user equipment may combine the PoC registration and the PoC publish request and may not give 
the user the possibility to do these actions separately. 
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6.4.5.2 Abstract Equation 



^ 1 1- 1 1 . unsuccessful PoC publish attempts 

PoC Publish Failure Ratio [%] = ^ *^xlOO 

all PoC publish attempts 



6.4.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC publish attempt 


Start: Attempt to publish the 
terminals PoC service 
settings. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
PUBLISH" message. 


Successful PoC publish 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" 
message. 


Unsuccessful PoC publish 
attempt 


Stop: PoC service settings 
are not published. 


Stop: Protocol: SIP 

Case 1 : Data packet received by the terminal containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 



6.4.6 PoC Publish Time [s] 

6.4.6.1 Abstract Definition 

The PoC publish time is the period of time that it takes to pubUsh the terminal's PoC service settings to the PoC server. 
Remarks: 

• To set, update or refresh the PoC service settings, the terminal generates a "SIP PUBLISH" request with XML 
MIME content according to rules and procedures of [17]. 

• The terminal shall be registered to the PoC service. 

• PoC enabled user equipment may combine the PoC registration and the PoC publish request and may not give 
the user the possibility to do these actions separately. 

6.4.6.2 Abstract Equation 



PoC Publish Time [S] = (tp^cPuWishEnd " tpoCPublishStart)[s] 



Terminal 




SIP Core 






SIP PUBLISH 






^ SIP 200 OK 





Figure 8: Example for a successful publish of PoC service settings 
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6.4.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Technical description/protocol part 


VoCPublishStart: "'"''^^ 

PoC publish attempt 


Start: Attempt to publish 
the terminals PoC 
service settings. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP PUBLISH" 
message. 


VoCPublishEnd: "^'"^^ 

successful PoC publish 
attempt 


Stop: PoC service 
settings are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 



6.4.7 PoC Registration Failure Ratio (long) [%] 

6.4.7.1 Abstract Definition 

The PoC registration failure ratio (long) is the probability that the terminal cannot successfully be registered to the PoC 
service and publish his PoC service settings. 

Remarks: 

• This QoS parameter is a combination of the PoC registration parameter (see clause 6.4.3) and the PoC publish 
parameter (see clause 6.4.5). It ought to reflect the behaviour of PoC enabled user equipment that may do the 
PoC publish automatically after the PoC register. 

• The terminal shall not be registered to the PoC service. 

6.4.7.2 Abstract Equation 



PoC Registration Failure Ratio (long) [%] = x 100 

all PoC registration (long) attempts 



6.4.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Teclinical description/protocol part 


PoC registration 
attempt 


Start: Activation of the 
PoC service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC publish 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 


Unsuccessful PoC 
publish attempt 


Stop: PoC service settings 
are not published. 


Stop: Protocol: SIP 

Case 1 : Data packet received by the terminal containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 
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6.4.8 PoC Registration Time (long) [s] 



6.4.8.1 Abstract Definition 

The PoC registration time (long) is the combined duration for a SIP registration and a SIP pubhsh. 
Remarks: 

• This QoS parameter is a combination of the PoC registration parameter (see clause 6.4.3) and the PoC publish 
parameter (see clause 6.4.5). It ought to reflect the behaviour of PoC enabled user equipment that may do the 
PoC publish automatically after the PoC register. 

• The terminal shall not be registered to the PoC service. 

6.4.8.2 Abstract Equation 



PoC Registration Time (long) [s] = (t 



PoCPublishEnd " ^ PoC Activated 



,)[s] 



Terminal 



SIP Core 





SIP REGISTER 




< — 


SIP 401 Unauthorized 


— 




SIP REGISTER 






SIP 200 OK 


— ► 


4 


SIP PUBLISH 






SIP 200 OK 


— ► 





Figure 9: Example for a successful PoC Registration (long) 
6.4.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Teclinical description/protocol part 


VoC Activated: "'"'■^^ 

PoC registration 
attempt 


Start: Activation of tine 
PoC service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


VoCPublishEnd: 

successful PoC publisli 
attempt 


Stop: PoC service settings 
are published. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 
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6.4.9 PoC Session Initiation Failure Ratio (on-demand) [%] 



6.4.9.1 Abstract Definition 

The PoC session Initiation failure ratio (on-demand) is the probability that a PoC session cannot be successfully 
initiated. A PoC session is initiated when the user pushes the PoC button on the terminal (and thereby requests a talk 
burst) and is granted a talk burst (see Figure 10). 

Remarks: 



• The terminal notifies the user about the granted Talk Burst (e.g. by a "beep" -tone). 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

• There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted 
(see [16]). If the PoC server supports media buffering, the talk burst confirm is send after the first received 
auto-answer. This automatic answer mode shall be used for the measurements and media buffering shall not be 
supported. In both cases (confirmed and unconfirmed) the trigger points for the measurement are the same. 
Measurement data of confirmed and unconfirmed measurements cannot be directly compared. 

• This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 

• The initial "SIP INVITE" message accepted by the PoC server is an implicit talk burst request. 



6.4.9.2 Abstract Equation 



^ ^ ^ . X • • • -t • / 1 IX n unsuccessful PoC session initiations , 

PoC Session Initiation Failure Ratio (on - demand) [%] = xlOO 

all PoC session initiations 



6.4.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Teclinical description/protocol part 


PoC session initiation 
attempt 


Start: PoC button is 
pushed. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
INVITE" message. 


Successful PoC 
session initiation 
attempt 


Stop: Talk burst granted 
is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 

"RTCP:TBCP Talk Burst Granted". 


Unsuccessful PoC 
session initiation 
attempt 


Stop: Missing talk burst 
granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP INVITE" message) containing an error 
message or redirection message (e.g. a "403 Forbidden" or 
"488 Not Acceptable Here" message). 

Case 2: First data packet received by the terminal (after 
sending a "SIP INVITE" message and receiving a "SIP 200 
OK" message) containing a message different to the 
"RTCP:TBCP Talk Burst Granted" message, e.g. "404 Not 
Found", "SIP 486 Busy Here" or "SIP 403 Forbidden" 
message. 

Case 3: No message received by the terminal within a 
pre-determined time. 
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6.4.10 PoC Session Initiation Time (on-demand) [s] 



6.4.10.1 



Abstract Definition 



The PoC session initiation time (on-demand) is the time period between pushing the PoC button on the terminal in order 
to initiate a PoC session and being granted the talk burst, e.g. indicated by a "beep" -tone on the terminal. 



• The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

• There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted 
(see [15]). If the PoC server supports media buffering, the talk burst confirm is send after the first received 
auto-answer. This automatic answer mode shall be used for the measurements and media buffering shall not be 
supported. In both cases (confirmed and unconfirmed) the trigger points for the measurement are the same. 
Measurement data of confirmed and unconfirmed measurements cannot be directly compared. 

• This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 

• The initial "SIP INVITE" message accepted by the PoC server is an implicit talk burst request. 



Remarks: 
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6.4.10.2 Abstract Equation 



PoC Session Initiation Time (on- demand) [s] = (tbeep received " tpoCbutto„pressed)[s] 



Terminal 



SIP Core 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



POC Server 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



RTCPiTBCP Talk Burst Granted 



SIP INVITE 

to terminating PoC 

Network 



SIP 180 Ringing 
from terminating PoC 
network 



SIP 200 OK 
from terminating PoC 
network 



Figure 10: Implicit talk burst request procedure at the initiation of the PoC session 



Remark: 



The dashed arrows in Figure 10 only occur in case of a confirmed invitation with manual answer. In this case 
the time that elapses between the "SIP INVITE" message and the reception of the "SIP 200 OK" message 
depends on how fast an invited user on the terminating side accepts the invitation. 



6.4.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


VoC button pressed: 

of PoC session initiation 
attempt 


Start: Pusli PoC button. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
INVITE" message. 


Wp received: 

successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 

"RTCP:TBCP Talk Burst Granted". 
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6.4.1 1 PoC Session Media Parameters Negotiation Failure Ratio 
(pre-established) [%] 

6.4.1 1 .1 Abstract Definition 

The PoC session media parameters negotiation failure ratio (pre-established) is the probability that a negotiation 
procedure of media parameters for a posterior pre-established session cannot be successfully accomplished. 



Remarks: 



The initial "SIP INVITE" message accepted by the PoC server is not an implicit talk burst request. 

All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

"The PoC server performing the controlling PoC function shall determine the codec(s) and media parameters 
that should be used in the PoC session. The preferred media parameters should be determined according to the 
lowest negotiated media parameters (e.g. bandwidth) of the terminals that have joined the PoC session 
(see [14], page 102)". 

"User plane adaptation may be triggered e.g. by roaming or when a new terminal with lower media parameters 
enters the PoC session (see [15], page 103)". 



6.4.1 1 .2 Abstract Equation 



PoC Session IVLedia Parameters Negotiation Failure Ratio (pre - established) [%] 
unsuccessfiil negotiation attempts 



all negotiation attempts 



-xlOO 



6.4.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Technical description/protocol part 


PoC session media 

parameters negotiation 
attempt 


Start: PoC terminal 

initiates media parameters 
negotiation. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP INVITE" 
message with media parameters. 


Successful PoC session 
media parameters 
negotiation attempt 


Stop: Successful 
parameter negotiation 
indication. 


Stop: Protocol: SIP. 

First "SIP Ack" data packet sent by the terminal after the reception 
of a "SIP OK" message. 


Unsuccessful PoC 
session media 
parameters negotiation 
attempt 


Stop: Media parameter 
negotiation is rejected or 
not indicated. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal (after sending a 
"SIP INVITE" message and receiving a "SIP 100 TRYING" 
message) containing a message different to "SIP 200 OK"; e.g. a 
""SIP 403 Forbidden" or "SIP 488 Not Acceptable Here" message. 

Case 2: No message received by the terminal within a 
pre-determined time. 
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6.4.12 PoC Session Media Parameters Negotiation Time 
(pre-established) [s] 

6.4.12.1 Abstract Definition 

The PoC session media parameters negotiation time (pre-established) describes the time period needed to accompHsh a 
successful negotiation of media parameters. 

Remarks: 

• The initial "SIP INVITE" message accepted by the PoC server is not an implicit talk burst request. 

• All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

• "The PoC server performing the controlling PoC function shall determine the codec(s) and media parameters 
that should be used in the PoC session. The preferred media parameters should be determined according to the 
lowest negotiated media parameters (e.g. bandwidth) of the terminals that have joined the PoC session 

(see [14], page 102)". 

• "User plane adaptation may be triggered e.g. by roaming or when a new terminal with lower media parameters 
enters the PoC session (see [14], page 103)". 

6.4.1 2.2 Abstract Equation 

PoC Session Media Parameters Negotiation Time (pre - established) [s] = (t^k received " t negotiation initiation 



Terminal SIP Core 




SIP INVITE 




► 

^ SIP 100 Trying 


^ SIP ^00 OK 


s;tp ack ^ 





Figure 11: Media parameters negotiation for pre-establishied session 



6.4.12.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^negotiation initiation: Time Of 

PoC pre-established 
session media 
parameters negotiation 
attempt 


Start: PoC terminal initiates 
media parameters negotiation. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
INVITE" message with Media Parameters. 


U received: ^ime Of 

successful PoC 
pre-established session 
media parameters 
negotiation attempt 


Stop: Successful parameter 
negotiation indication. 


Stop: Protocol: SIP. 

First "SIP Ack" data packet sent by the terminal after the 
reception of a "SIP OK" message. 



ETSI 



76 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



6.4.13 PoC Session Initiation Failure Ratio (pre-established) [%] 



6.4.13.1 



Abstract Definition 



The PoC session initiation failure ratio (pre-established) is the probability that a pre-established session cannot be 
successfully initiated. After the negotiation of media parameters, a pre-established session is initiated when the user 
pushes the PoC button on the terminal (and thereby requests the talk burst) and is granted the talk burst. 



• The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

• The initial "SIP REFER" message accepted by the PoC server is an implicit talk burst request. 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• The terminals shall have negotiated the session media parameters with the PoC server. 

• All terminals in the PoC session shall be configured to use the auto-answer mode procedure (see [16]). 

• There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted. 
The terminals on the terminating side may be configured to confirm the invitation automatically. This 
auto-answer mode should be used for measurements. In both cases (confirmed and unconfirmed) the trigger 
points for the measurement are the same. Measurement data of confirmed and unconfirmed measurements 
cannot be directly compared. 

• This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 



Remarks: 



6.4.13.2 Abstract Equation 



PoC Session Initiation Failure Ratio (pre - established) [%] = 

unsuccessful pre - established session initiation attempts 



xlOO 



all pre - established session initiation attempts 
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6.4.13.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC session initiation 
attempt 


Start: PoC button is pushed. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER" message with the PoC session URL. 


Successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing "Talk 
Burst Granted" message. 


Unsuccessful PoC 
session initiation attempt 


Stop: Missing talk burst 
granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 
Case 1 : First data packet received by the terminal (after 
sending a "SIP REFER" message) containing a message 
different to the "SIP 202 Accepted" message. 

Case 2: Data packet received by the terminal (after sending a 
"SIP REFER" message and receiving a "SIP 202 Accepted" 
message) containing a message different to "SIP NOTIFY", 
"RTCP:TBCP Connect" or "RTCP:TBCP Talk Burst Granted" 
(e.g. "SIP 404 Not Found", "SIP 486 Busy Here" or "SIP 403 
Forbidden" message). 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.14 PoC Session Initiation Time (pre-established) [s] 
6.4.14.1 Abstract Definition 

The PoC session initiation time (pre-established) is the time period between pushing the PoC button on the terminal in 
order to initiate a pre-established session and being granted the talk burst, e.g. indicated by a "beep" -tone on the 
terminal. 

Remarks: 

• The terminal notifies the user about the granted talk burst (e.g. by a "beep"-tone). 

• The initial "SIP REFER" message accepted by the PoC server is an implicit talk burst request. 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• The terminals shall have negotiated the session media parameters with the PoC server. 

• All terminals in the PoC session shall be configured to use the auto-answer mode procedure (see [16]). 

• There are different signal flows for confirmed and for unconfirmed invitations. In the confirmed case, at least 
one of the invited users has to accept the invitation to the PoC session in order to get the talk burst granted. 
The terminals on the terminating side may be configured to confirm the invitation automatically. This 
auto-answer mode should be used for measurements. In both cases (confirmed and unconfirmed) the trigger 
points for the measurement are the same. Measurement data of confirmed and unconfirmed measurements 
cannot be directly compared. 

• This parameter is applicable to different kinds of PoC session initiations, which has an impact on the 
comparability of the measurement data. 
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6.4.14.2 Abstract Equation 



PoC Session Initiation Time (pre- established) [s] = (tbeep received -tpoc button pressed 



Terminal 



SIP Core 



SIP REFER 



SIP 202 Accepted 



SIP NOTIFY 
SIP 200 OK 



POC Server 



STPRRFRR 



SIP 202 Accepted 



SIP NOTIFY 



SIP 200 OK 



RTCPiTBCP Connect 



RTCP:TBCP Acknowledged 



RTCP:TBCP Ta k Burst Granted 



SIP INVITE 
to terminating 
PoC Network 



SIP NOTIFY 
informing invitation 
progress 



NOTE: The dashed arrows in this Figure only occur in case of a confirmed, manual answer invitation. In this case 
the time period between the "SIP INVITE" message and the reception of the "Talk Burst Granted" 
message depends on how fast an invited user on the terminating side answers to the invitation. 
Furthermore, the "SIP NOTIFY" message is defined as optional (see [15]) and might not be sent by the 
server at all. For this reason the automatic answer mode shall be used during measurements. 

Figure 12: Talk burst request procedure of a pre-established PoC session 

6.4.14.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


VoC button pressed: 

PoC session initiation 
attempt 


Start: Push PoC button. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER" message with the PoC session description. 


^beep received: 

successful PoC session 
initiation attempt 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTGP:TBGP. 

First data packet received by the terminal containing "Talk 
Burst Granted" message. 



6.4.15 PoC Session Setup Failure Ratio (on-demand) [%] 
6.4.15.1 Abstract Definition 

The PoC session setup failure ratio (on-demand) is the probability that a terminal cannot successfully register to the 
PoC service and initialize an on-demand session. 
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Remarks: 

• This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 

6.4.1 5.2 Abstract Equation 

Let R be the number of unsuccessful registration attempts and let S be the number of unsuccessful session initiations 
following a successful registration. 

Then: 



PoC Session Setup Failure Ratio (on - demand) [%] = x 100 

all PoC session setup attempts 



6.4.15.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC registration attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC session 
initiation attempt 


Stop: PoC available is 
indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 

"RTCP;TBCP Talk Burst Granted". 


Unsuccessful PoC 
session initiation attempt 


Stop: Missing Talk Burst 
Granted indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 

sending a "SIP INVITE" message) containing an error 

message or redirection message (e.g. a "403 Forbidden" or 

"488 Not Acceptable Here" message). 

Case 2: First data packet received by the terminal (after 

sending a "SIP INVITE" message and receiving a "SIP 200 

OK" message) containing a message different to the 

"RTCP:TBCP Talk Burst Granted" message, e.g. "404 Not 

Found", "SIP 486 Busy Here" or "SIP 403 Forbidden" 

message. 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.16 PoC Session Setup Failure Ratio (pre-established) [%] 

6.4.16.1 Abstract Definition 

The PoC session setup failure ratio (pre-established) is the probability that a terminal cannot successful register to the 
PoC service and initialize a pre-established session. 

Remarks: 

• This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 

6.4.1 6.2 Abstract Equation 

Let R be the number of unsuccessful registration attempts and let S be the number of unsuccessful pre-established 
session media parameters negotiations following a successful registration. Let The the number of unsuccessful session 
initiation attempts, which followed after a successful registration and after a successful pre-established session media 
parameters negotiation. 
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Then: 



PoC Session Setup Failure Ratio (pre - established) [%] = x 100 

all PoC session setup attempts 



6.4.16.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful PoC session 
initiation attempt 


Stop: PoC available is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 

"RTCP;TBCP Talk Burst Granted". 


Unsuccessful PoC 
session initiation 
attempt 


Stop: Missing talk burst granted 
indication. 


Stop: Protocol: SIP; RTCP:TBCP. 

Case 1 : First data packet received by the terminal (after 
sending a "SIP REFER" message) containing a message 
different to the "SIP 202 Accepted" message. 

Case 2: Data packet received by the terminal (after sending 
a "SIP REFER" message and receiving a "SIP 202 
Accepted" message) containing a message different to "SIP 
NOTIFY", "RTCP:TBCP Connect" or "RTCP:TBCP Talk 
Burst Granted" (e.g. "SIP 404 Not Found", "SIP 486 Busy 
Here" or "SIP 403 Forbidden" message). 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.1 7 PoC Session Setup Time [s] 
6.4.1 7.1 Abstract Definition: 

The PoC session setup time is the time period for the registration to the PoC service plus the time period for the 
initiation of a PoC session. 

Remarks: 

• This QoS parameter is a combination of the PoC registration parameter and the PoC session initiation 
parameter. It is ought to reflect the behaviour of PoC enabled user equipment. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 

• Data between on-demand sessions and pre-established sessions cannot be compared directly. 
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QAM. 2 Abstract Equation 



POC Session Setup Time [S] = (tbeep received - tpoCActivated)[s] 



PoC 
Session 



Terminal #1 



PoC Server 



Terminal #2 



SIP session establishment 
with UE #1 



SIP session establishment 
with UE #2 



RTP media streaming 



-JITCP:TBCP Floor Taken 



RTP media streaming 



^ PoC Push 
To Speech 



Figure 13: PoC session setup time and PoC push to speal( time 

6.4.17.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


VoC Activated: "'"''^^ 

PoC registration 
attempt 


Start: Activation of tine PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Wp received: "'"''^^ 

successful PoC 
registration attempt 


Stop: PoC available is indicated. 


Stop: Protocol: RTCP:TBCP 

First data packet received by the terminal containing 

"RTCP;TBCP Talk Burst Granted". 



6.4.18 PoC Push to Speak Failure Ratio [%] 



6.4.1 8.1 Abstract Definition 

The PoC Push to speak failure ratio is the probability that terminal A cannot successfully set up a PoC session and start 
with speech leading to no other terminal receiving speech. 

Remarks: 

• This QoS parameter is a combination of the PoC session setup parameter and the PoC talk burst cut-off 
parameter (see clause 6.4.30). It is ought to reflect the behaviour of PoC enabled user equipment. 

• All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 



6.4.18.2 Abstract Equation 

Let S be the number of unsuccessful PoC session setup attempts and let T be the number of talk burst cut-offs following 
a successful PoC session setup. 
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Then: 



PoC Push to Speak Failure Ratio [%] = x 100 

all PoC push to speak attempts 



6.4.18.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


PoC registration 
attempt 


Start: Activation of the PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


No unintended speech 
cut-off on terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 
data. 


Unintended speech 
cut-off on terminal B 


Stop: Terminal B does not 
receive speech or does not 
receive the whole speech. 


Stop: Protocol: RTP. 

Case 1 : No packet containing speech data (RTP media 
stream) received by terminal B within a pre-determined time. 
The timeout should be chosen greater than the average 
speech delay (see clause 6.4.32). 

Case 2: The media stream is only partially received by 
terminal B. Some of the data packets containing speech data 
(RTP media stream) have not been received by terminal B. 



6.4.19 PoC Push to Speak Time [s] 

6.4.19.1 Abstract Definition 

The PoC push to speak time is the period of time that it takes to setup a PoC session and start with speech in addition to 
the delay until terminal B receives the speech (as defined in clause 6.4.32). 

Remarks: 

• This QoS parameter is a combination of the PoC session setup time parameter and the PoC speech 
transmission delay parameter (see clause 6.4.32). It ought to reflect the behaviour of PoC enabled user 
equipment. 

• All terminals shall be registered to the PoC service and shall have successfully published their PoC service 
settings. 

• Data between confirmed and unconfirmed measurements cannot be compared directly. 

6.4.1 9.2 Abstract Equation 



PoC Push to Speak Time [S] = (t^ ^ears - tpoCActivated)[s] 



6.4.19.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^PoCActivated: 

PoC registration 
attempt 


Start: Activation of tlie PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


tB_hears: Time Of OUtput 

at terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 
data. 
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6.4.20 PoC Session Leaving Failure Ratio (on-demand) [%] 

6.4.20.1 Abstract Definition 

The PoC session leaving failure ratio (on-demand) is the probability that the user cannot leave the PoC session he is 
participating. 

Remarks: 

• When a PoC session is left, the terminal is still registered to the PoC service. 

• PoC enabled user equipment may not give the user the possibility to leave a PoC session explicitly. The PoC 
session leave request may only be sent when the terminal deregisters from the PoC service. 

• The terminal shall be registered to the PoC service participating in a PoC session. 

6.4.20.2 Abstract Equation 

PoC Session Leaving Failure Ratio (on - demand) [%] = 

unsuccessfiil PoC session leaving attempts , 
^— xlOO 

all PoC session leaving attempts 



6.4.20.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


PoC session leaving 
attempt 


start: Leaving the participating 
PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a 
"SIP BYE" message. 


Successful PoC session 
leaving attempt 


stop: PoC session left is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing 
a "SIP 200 OK" message. 


Unsuccessful PoC 
session leaving attempt 


Stop: Terminal is still connected 
to the PoC session. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal 
(after sending the "SIP BYE" message) containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within 
a pre-determined time. 



6.4.21 PoC Session Leaving Time (on-demand) [s] 
6.4.21 .1 Abstract Definition 

The PoC session leaving time (on-demand) is the time period between sending the on-demand session leaving request 
and being disconnected from the on-demand session. 

Remarks: 

• When a PoC session is left, the terminal is still registered to the PoC service. 

• PoC enabled user equipment may not give the user the possibility to leave a PoC session explicitly. The PoC 
session leave request may only be sent when the terminal de-registers from the PoC service. 

• The terminal shall be registered to the PoC service participating in a PoC session. 
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6.4.21 .2 Abstract Equation 



PoC Session Leaving Time (on - demand) [s] = (t 



session left ~ ^session leave request 



)[s] 



Terminal 



SIP Core 



SIP BYE 



SIP 200 OK 
< 



Figure 14: Successful PoC session leaving 



6.4.21.3 Trigger Points 



Event from 
abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^session leave request: 

Time of PoC 
session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP BYE" 
message. 


^session left: Time Of 

successful PoC 
session leaving 
attempt 


Stop: PoC session left is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
200 OK" message. 



6.4.22 PoC Session Leaving Failure Ratio (pre-established) [%] 



6.4.22.1 Abstract Definition 

The PoC session leaving failure ratio (pre-established) is the probability that the user cannot leave the PoC 
pre-established session he is participating. 

Remarks: 



• The PoC session v^as established using pre-established signalling. 

• The terminal may not give the user the possibility to leave a PoC session explicitly. The PoC session leave 
request may only be sent when the terminal deregisters from the PoC service. 

6.4.22.2 Abstract Equation 



PoC Session Leaving Failure Ratio (pre - established) [%] = 
unsuccessful PoC session leaving attempts 



all PoC session leaving attempts 



-xlOO 
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6.4.22.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER BYE" message. 


Successful PoC session 
leaving attempt 


Stop: Terminal has 
successfully left the PoC 
session. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
202 ACCEPTED" message. 


Unsuccessful PoC session 
leaving attempt 


Stop: Terminal is still 
connected to the PoC 
session. 


Stop: Protocol: SIP 

Case 1 : First data packet received by the terminal (after 
sending the "SIP REFER BYE" message) containing a 
message different to "SIP 202 Accepted". 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.4.23 PoC Session Leaving Time (pre-established) [s] 

6.4.23.1 Abstract Definition 

The PoC session leaving time (pre-established) is the time period between sending the PoC session leaving request and 
being disconnected from the Pre-established session. 

Remarks: 

• The PoC session was established using Pre-established signalling. 

• The terminal may not give the user the possibility to leave a PoC session explicitly. The PoC session leave 
request may only be sent when the terminal deregisters from the PoC service. 

6.4.23.2 Abstract Equation 



PoC Session Leaving Time (pre - established) [s] = (t,essionieft - tsessionieaverequest)[s] 



Terminal 




SIP Core 






SIP REFER BYE 










SIP 202 ACCEPTED 


> 











Figure 15: Successful PoC session leaving (Pre-established session) 
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6.4.23.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^session leave request: "'"''^^ 

PoC session leaving 
attempt 


Start: Leaving the 
participating PoC session. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REFER BYE" message. 


^session left: ^ime Of 

successful PoC session 
leaving attempt 


Stop: Terminal has 
successfully left the PoC 
session. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
202 ACCEPTED" message. 



6.4.24 PoC Deregistration Failure Ratio [%] 

6.4.24.1 Abstract Definition 

The PoC deregistration failure ratio is the probabihty that the user can not be deregistered from the Push to Talk over 
Cellular service when requested. 

Remark: 

• The terminal shall be registered to the PoC service. 

6.4.24.2 Abstract Equation 



^ . . . unsuccessful PoC deregistration attempts 

PoC Deregistration Failure Ratio [%] = xlOO 

all PoC deregistration attempts 



6.4.24.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC deregistration attempt 


Start: Deactivation of the 
PoC service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
Register" message, where the "Expires" header is set to 0. 


Successful PoC 
deregistration attempt 


Stop: PoC unavailable is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 
200 OK" message. 


Unsuccessful PoC 
deregistration attempt 


Stop: PoC unavailable 
indication is not given within 
a predetermined time. 


Stop: Protocol: SIP. 

Case 1 : First data packet received by the terminal (after 
sending the second "SIP REGISTER" message) containing a 
message different to "SIP 200 OK". 

Case 2: No message received by the terminal within a 
pre-determined time. 



6.4.25 PoC Deregistration Time [s] 
6.4.25.1 Abstract Definition 

The PoC deregistration time is the time period between the deregistration request and the successful deregistration from 
the PoC service. 

Remark: 

• The terminal shall be registered to the PoC service. 
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6.4.25.2 Abstract Equation 

PoCDeregistrationTime [S] = (tpoCderegiste^d "tderegistration request 



Terminal SIP Core 




SIP REGISTER 




► 

SIP 401 UNAUTHORIZED 


< 

SIP REGISTER 


► 

SIP 200 OK 


< 



Figure 16: Successful PoC deregistration example 



6.4.25.3 Trigger Points 



Event from 
abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^deregistration request: 

Time of PoC 

deregistration 

attempt 


Start: Deactivation of tine PoC 
service on the terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP Register" 
message, where the "Expires" header is set to 0. 


VoC deregistered: 

Time of successful 
PoC deregistration 
attempt 


Stop: PoC unavailable is 
indicated. 


Stop: Protocol: SIP. 

First data packet received by the terminal containing a "SIP 200 
OK" message. 



6.4.26 PoC Busy Floor Response Failure Ratio [%] 

6.4.26.1 Abstract Definition 

The PoC busy floor response failure ratio is the probabihty that, once in a PoC session, the talk burst request from the 
terminal fails. 

Remarks: 

• The terminal shall be within an active PoC talk session. Thus, there shall be at least one other participating 
terminal. 

• For the special case of requesting the idle floor, there are defined further QoS parameters (see clauses 6.4.28 
and 6.4.29). 

6.4.26.2 Abstract Equation 



^ ^ ^ . r^n unsuccessful talk burst requests 

PoC Busy Floor Response Failure Ratio [%] = xlOO 

all talk burst requests 
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6.4.26.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 

"RTCP:TBCP Talk Burst Request" message. 


Successful PoC talk 
burst request 


Stop: Current floor state is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing 

information about the floor state. 


Unsuccessful PoC talk 
burst request 


Stop: No talk burst response is 
indicated (e.g. grant, queued). 


Stop: Protocol: RTCP:TBCP. 

No message received by the terminal within a 

pre-determined time. 



6.4.27 PoC Busy Floor Response Time [s] 

6.4.27.1 Abstract Definition 

The PoC busy floor response time is the is the time period between requesting the talk burst and receiving the indication 
the floor is busy within an already established PoC session. 

Remarks: 

• The terminal shall be within an active PoC talk session. Thus, there shall be at least one other participating 
terminal. 

• For the special case of requesting the idle floor, there are defined further QoS parameters (see clauses 6.4.28 
and 6.4.29). 

6.4.27.2 Abstract Equation 



PoC Busy Floor Response Time[s] = (tfl,,, response - tfioor request 





Terminal 




r \ 
PoC Server 


Floor Response 1 
Time 


RTCP:TBCP Floor 
Request 

RTP Queued 






4 



Figure 17: Example for a busy floor response 



6.4.27.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


tfloor request: Time Of PoC 
talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 

"RTCP:TBCP Talk Burst Request" message. 


Wr response: "'"''^^ 

successful PoC talk burst 
request 


Stop: Current floor state is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing 

information about the floor state. 
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6.4.28 PoC Talk Burst Request Failure Ratio [%] 

6.4.28.1 Abstract Definition 

The PoC talk burst request failure ratio is the probability that, once in a PoC session, the terminal's request of the idle 
floor fails. 

Remarks: 

• The terminal shall be within an active PoC session. 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• This parameter is defined explicitly because the server's response time and failure ratio to a request of the idle 
floor may be different to the response time and response failure ratio of a busy floor. 

6.4.28.2 Abstract Equation 



^rx. 11 ^ ^ .1 . unsucccssful talk buist rcQuests 

PoC Talk Burst Request Failure Ratio [%] = ^ xlOO 

all talk burst requests 



6.4.28.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC talk burst request 


start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 

"RTCP:TBCP Talk Burst Request" message. 


Successful PoC talk 
burst request 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing a 
"RTCP:TBCP Talk Burst Granted" message. 


Unsuccessful PoC talk 
burst request 


Stop: Talk burst granted is not 
indicated. 


Stop: Protocol: RTCP:TBCP. 

Case 1 : First data packet received by the terminal 
containing a floor state different to "RTCP:TBCP Talk 
Burst Granted". Possible floor states are listed in [14]. 

Case 2: No message received by the terminal within a 
predetermined time. 



6.4.29 PoC Talk Burst Request Time [s] 
6.4.29.1 Abstract Definition 

The PoC talk burst request time is the time period between requesting the talk burst and being granted the previously 
idle floor within an already established PoC session. 

Remarks: 

• The terminal shall be within an active PoC session. 

• There shall be at least one other participating terminal and the floor shall be idle. In particular, no other 
terminal shall create and send data packets containing speech data (RTP media stream). 

• This parameter is defined explicitly because the server's response time and failure ratio to a request of the idle 
floor may be different to the response time and response failure ratio of a busy floor. 
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6.4.29.2 Abstract Equation 



PoCTalkBurstRequestTime [s] = (tfl,,,g,,nted " tfloor request 



Terminal 



PoC Server 



Talk Burst Request I 
Time 



Floor idle 



RTCP:TBCP Talk Burst 
Request 



RTCP:TBCP Talk Burst 
Granted 



Figure 18: Example for a successful talk burst request 



6.4.29.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


tfloor request: Time Of PoC 

talk burst request 


Start: Push PoC button. 


Start: Protocol: RTCP:TBCP. 

First data packet sent by the terminal containing a 

"RTCP:TBCP Talk Burst Request" message. 


tfloor granted: Time Of 

successful PoC talk burst 
request 


Stop: Talk burst granted is 
indicated. 


Stop: Protocol: RTCP:TBCP. 

First data packet received by the terminal containing a 
"RTCP:TBCP Talk Burst Granted" message. 



6.4.30 PoC Talk Burst Cut-off Ratio [%] 



6.4.30.1 Abstract Definition 

The PoC talk burst cut-off ratio is the probability that the terminal on the originating side (terminal A) has the floor and 
creates and sends data packets containing speech data (RTP media stream), but the stream does not arrive (or arrives 
only partly) at the terminating side (terminal B). 

Remarks: 



• There shall be at least one other active participating terminal and the floor shall be granted to terminal A. In 
particular, no other terminal shall create and send data packets containing speech data (RTP media stream). 

• The implementation of a stop-talking timer is mandatory on the server side. When a user is granted a talk 
burst, the PoC server resets this stop-talking timer. When the timer expires, the PoC server revokes the talk 
burst from the user (see [14]). Hence this situation (talk burst revoked because of a timeout) shall not be 
considered for measurements. 

• The time of a talk burst shall be shorter than the network-defined stop-talking timeout. 



6.4.30.2 Abstract Equation 



^ ^ rx. ^ ^ nn ^ ' rrr^n dropDcd talk butsts , 

PoC Talk Burst Cut - off Ratio [%] = ^ xlOO 

all talk bursts 
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Terminal A 



PoC Server 



Terminal B 



Terminal A creates 
speech 



I 



Floor idle 



RTCP:TBCP: Talk Burst 
Request 



RTCP:TBCP: Talk Burst 
Granted 



RTP: Media Stream 



RTCP:TBCP: Talk Burst Taken 



RTP: Media Stream 



Terminal B does not receive 
the complete speech 



Figure 19: PoC talk burst cut-off 



6.4.30.3 Trigger Points 



Event from abstract 
equation 



Trigger point from user's 
point of view 



Teclinical description/protocol part 



PoC talk burst granted 
and start of speech on 
terminal A 



Start: Talk burst granted is 
indicated. Speech starts. 



Start: Protocol: RTP. 

First data packet sent by terminal A containing speech 
data. 



No unintended speech 
cut-off on terminal B 



Stop: Sound received by 
terminal B. 



Stop: Protocol: RTP. 

First data packet received by terminal B containing 
speech data. 



Unintended speech 
cut-off on terminal B 



Stop: Terminal B does not 
receive speech or does not 
receive the whole speech. 



Stop: Protocol: RTP. 

Case 1 : No packet containing speech data (RTP media 
stream) received by terminal B within a pre-determined 
time. The timeout should be chosen greater than the 
average speech delay (see clause 6.4.32). 



Case 2: The media stream is only partially received by 
terminal B. Some of the data packets containing speech 
data (RTP media stream) have not been received by 
terminal B. 



6.4.31 PoC Talk Burst Packet Drop Ratio [%] 



6.4.31 .1 Abstract Definition 

The PoC talk burst packet drop ratio is the ratio between the number of data packets containing speech data sent by the 
terminal on the originating side (terminal A) and the number of data packets containing speech data received on the 
terminating side (terminal B). 

Remarks: 



• There shall be at least one other active participating terminal and the floor shall be granted to terminal A. In 
particular, no other terminal shall create and send data packets containing speech data (RTP media stream). 

• The implementation of a stop-talking timer is mandatory on the server side. When a user is granted a Talk 
Burst, the PoC server resets this stop-talking timer. When the timer expires, the PoC server revokes the talk 
burst from the user (see [14]). Hence this situation (talk burst revoked because of a timeout) shall not be 
considered for measurements. 

• The time of a talk burst shall be shorter than the network-defined stop-talking timeout. 
This ratio shall get calculated on a per-burst basis. 
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6.4.31 .2 Abstract Equation 



PoC Talk Burst Packet Drop Ratio [%] = dropped RTP speech packets ^ 

all sent RTP speech packets 



6.4.31.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


PoC talk burst granted 
and start of speech on 
terminal A 


Start: Talk burst granted is 
indicated. Speech starts. 


Stop: Protocol: RTP. 

First data packet sent by terminal A containing speech data. 


End of speech on 
terminal B 


Stop: End of speech is indicated 
or timeout occurred after 
terminal B has received speech. 


Stop: Protocol: RTP. 

Case 1 : First packet received by the terminal containing a 
"RTP: Last Packet" message after a data packet containing 
speech data has been received by terminal B. 

Case 2: No packet containing a "RTP: Last Packet" message 
received by terminal B within a pre-determined time after a 
data packet containing speech data has been received by 
terminal B. 



6.4.32 PoC Voice Transmission Delay (first) [s] 
6.4.32.1 Abstract Definition 

The parameter PoC speech transmission delay (first) describes the period of time between a terminal sending speech 
data (RTP media stream) and the first terminal receiving the speech data for the first talk burst after a PoC session has 
been established successfully. 

Remarks: 

• Without loss of generality, the PoC session consists only of two active terminals (A and B) and terminal A is 
trying to create and send data packets containing speech data (RTP media stream). Thus, terminal B is the one 
who should receive the corresponding RTP media stream. 

• Server side buffering has a high impact on measurement results. Depending on the configuration of the server, 
the PoC speech transmission delay (first) might in fact just describe the transmission delay between the server 
and terminal B. To avoid buffering at server side, confirmed indication shall be used. 

• Terminal A shall create an RTP media stream immediately after being granted the talk burst. 

• This parameter is measured on the transport layer. Thus the measured value may be smaller than the real user 
perceived speech delay. The perceived delay also depends on the encoding/decoding speed of the terminals. 
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6.4.32.2 Abstract Equation 



PoC Voice Transmission Delay (first) [s] = (te hears " t A_speaks ) [s] 



Terminal A 



PoC Server 



Terminal B 



SIP session establishment 
with terminal #1 



RTCP:TBCP Floor 



SIP session establishment 
with terminal #2 



Granted 


RTCP:TBCP Floor Taken 






RTP Media Stream 


RTP Media Stream 












PoC Speech 
delay (first) 



Figure 20: PoC speech transmission delay (first) and PoC speech transmission delay (others) 



6.4.32.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Vspeaks: Time of input at 
terminal A 


Start: Terminal A got the 
talk burst granted and 
creates an RTP media 
stream (starts talking). 


Start: Protocol: RTP. 

First data packet sent by terminal A containing speech data. 


te.hears: ^'^^^ Output at 

terminal B 


Stop: Sound received by 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing speech 
data. 



6.4.33 PoC Speech Transmission Delay (others) [s] 
6.4.33.1 Abstract Definition 

The parameter PoC speech transmission delay (others) describes the period of time between a terminal sending speech 
data (RTP media stream) and the first terminal receiving the speech data (within an already established PoC session). 

Remarks: 

• Without loss of generality, the PoC session consists only of two active terminals (A and B) and terminal A is 
trying to create and send data packets containing speech data (RTP media stream). Thus, terminal B is the one 
who should receive the corresponding RTP media stream. 

• Server side buffering has a high impact on measurement results. Depending on the configuration of the server, 
the PoC speech transmission delay (first) might in fact just describe the transmission delay between the server 
and terminal B. To avoid buffering at server side, confirmed indication shall be used. 

• Terminal A shall create an RTP media stream inmiediately after being granted the talk burst. 
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• This parameter is measured on the transport layer. Thus the measured value may be smaller than the real user 
perceived speech delay. The perceived delay also depends on the encoding/decoding speed of the terminals. 

• The speech delays on the terminating site depend on where the terminals are located (e.g. in another cell or 
another network). 

6.4.33.2 Abstract Equation 



PoC Voice Transmission Delay (others) [s] = (tg ^^ars " tA_speaks)[s] 



6.4.33.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Vspeaks: ^ime of input at 
terminal A 


Start: Terminal A got the talk 
burst granted and creates an 
RTP media stream (starts 
talking). 


Start: Protocol: RTP. 

First data packet sent by terminal A containing 
speech data. 


te.hears: ^'me of output at 
terminal B 


Stop: Sound received at 
terminal B. 


Stop: Protocol: RTP. 

First data packet received by terminal B containing 
speech data. 



6.4.34 PoC Speech Quality 

To be defined. 

6.4.35 Group Management QoS Parameter 

To be defined. 

6.4.36 Group Document related QoS Parameter 

To be defined. 

6.4.37 Instant Message QoS Parameter 

To be defined. 

6.5 Streaming Video 

6.5.1 Definitions 

6.5.1 .1 Streaming Session or Session 

RFC 2326 [8] defines a session as "a complete RTSP "transaction", e.g. the viewing of a movie. A session typically 
consists of a client setting up a transport mechanism for the continuous media stream (SETUP), starting the stream with 
PLAY or RECORD, and closing the stream with TEARDOWN". 

Referring to Figure 21 this means that the session starts at (B) and stops at (G). 
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6.5.2 Prerequisites 



Precondition 


Covered by 


Reference document 


Comment 


Network Accessibility 
given 


Network Accessibility Indicator 






PDP context activated 









6.5.3 Streaming Scenarios 

The following two clauses describe different streaming scenarios. The first one is a generic approach in order to 
understand the main principles and identify the relevant protocols and communication procedures. 

6.5.3.1 Generic Streaming Signalling Flow 

A generic signal flow description for streaming is shown in Figure 21. The client communicates with the web server 
and media server entities and uses different protocols during the complete procedure, e.g. RTP, RTSP, RTCP, 
HTTP, etc. 



The next table gives a basic description of the protocols and their usage. 



Protocol 


Reference in 
Figure 21 


Description 


HTTP 


A 


Used for the retrieval of the streaming file description data. 


RTSP 


B,G,F,G 


RTSP is an application-level protocol. It provides different methods for the control of 
real-time data, e.g. audio/video (see note 1). 


RTP 


D 


RTP is used for the transmission of real-time data, e.g. audio/video (see note 2). 


RTCP 


E 


RTCP is the control protocol for RTP. Its main function is the provision of a quality 
feedback. 


NOTE 1 : RTSP is not responsible for the delivery of the data, this is done by RTP. 

NOTE 2: RTP is only used for the delivery of the data. No control and/or QoS are included. 







HTTP GET 






O 




Session Description 


-► 


Web 
Server 






















o 




RTSP: SETUP 










-► 






RTSP: PLAY 






e 






-► 




Client 




RTP Audio 






o 


<- 


RTP Video 




Media 
Server 




RTCP 




o 






-► 


o 
o 




Example: RTSP: PAUSE 










-► 






CLOSE 










-► 









Figure 21 : Generic session signalling flow, based on Schulzrinne 
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Referring to Figure 2 land the definition of a session in clause 6.5.1.1 it is possible to divide the communication of the 
cHent with the server side in two phases: 

• In the first phase the client communicates with the web server in order to get a description of the file to be 
streamed. The used protocol is HTTP. Starting point is (A) and ending point is (B). 

• In the second phase starts the communication with the media server which is finally delivering the stream. This 
means that the session starts at (B) and stops at (G). Different protocols are used in this phase (RTSP, RTF, 
RTCP, etc.). 

6.5.3.2 Parameter Overview Chart 

Figure 22 gives an overview of the defined QoS parameters with their trigger points from user's point of view. 



Parameters 




Streaming Reproduction 
Cut-Off Ratio [%], 
(Precond.: Service Access 






Streaming Video Quality [] 


:}::■::■:■:■:■:■:■:■: 




Streaming 
Service Non- 
Accessability [%] 




Streaming Reproduction 
Start Failure Ratio [%], 
(Precond. Service Access) 


N 


Streaming Audio Quality [] 
[M0S-BS1 387-1] 


:(:■::■::■::■::■> 
: :k 


Streaming 
Service Access Time 
[s], (Precond. Servic 


Streaming Reproduction 
Start Delay [s], 
(Precond. Service Access) 


Streaming Audio / Video 
De-Synchronisation [%] 


















Trigger Points 
from 
Customer's 
Doint of View 


Stream Request 


Buffering Message 
appears on Player 






Stream Reproduction 


Intentional 
Termination of 
Session 




to 




t1 




t2 




t3 



Figure 22: Parameter overview with trigger points 



6.5.4 Streaming Service Non-Accessibility [%] 

6.5.4.1 Abstract Definition 

The parameter Streaming Service Non- Accessibility describes the probabiHty that the first data packet of the stream 
cannot be received by the UE when requested by the user. The "packet reception" is completed by appearance of the 
"buffering" message on the player at user side. 

The first data packet refers to RTP protocol. 

6.5.4.2 Abstract Equation 



. . A -1 unsucccssful strcam rcqucst attcmpts 

Streaming Service Non - Accessibility [%] = — x 100 

all stream request attempts 
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6.5.4.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Service access attempt 


Start: Stream request. 


Start: 

• WAP 1 .X, WAP 2.x: 
WSP Disconnect; 

• WAP 2.x: TCP SYN towards streaming 
platform. 


Successful attempt 


Stop: "Buffering" message. 


Stop: Reception of first data packet. 


Unsuccessful attempt 


Stop trigger point not reached. 



6.5.5 Streaming Service Access Time [s] 

6.5.5.1 Abstract Definition 

The parameter Streaming Service Access Time describes the duration of a service access from requesting the stream at 
the portal until the reception of the first stream data packet at the UE. 

The first data packet refers to RTP protocol. 

6.5.5.2 Abstract Equation 



StreamingService AcCeSSTime [S] = (treception of first data packet - tstreamrequest)[s] 



6.5.5.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^stream request^ ^ime when Stream 
is requested 


Start: Stream request. 


Start: 

• WAP 1.x, WAP 2.x: 
WSP Disconnect; 

• WAP 2.x: TCP SYN towards streaming 
platform. 


deception of first data packet" 

when first data packet is received 


Start: "Buffering" message. 


Stop: Reception of first data packet. 



6.5.6 Streaming Reproduction Cut-off Ratio [%] 

6.5.6.1 Abstract Definition 

The parameter Streaming Reproduction Cut-off Ratio describes the probabihty that a successfully started stream 
reproduction is ended by a cause other than the intentional termination by the user. 

6.5.6.2 Abstract Equation 



..^ ' unintenionallv teriimated strcam rcproductions 

Streaming Reproduction Cut - off Ratio [%] = x 100 

all successfully started stream reproductions 
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6.5.6.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started media 
streaming reproduction 


Start: Stream reproduction starts. 


Start: Streaming player signals the start of the 
stream reproduction. 


Intentional terminated streaming 
reproduction 


Stop: User presses the "Exit" 
button or end of stream is reached. 


Stop: RTSP Teardown method sent by UE and 
reception of confirmation "RTSP 200 OK" from 
media server. 


Unintentional terminated 
streaming reproduction 


Stop trigger point not reached. 


NOTE: Not all players may signal the reproduction start. 



Some players do not send this TEARDOWN command at the end of the stream but a PAUSE conmiand or in some 
cases nothing at all. On the server side a logic can then identify the status of the streams/clients. 

Used players should send the RTSP:TEARDOWN conmiand in order to give a stable trigger point for measurements. 

6.5.7 Streaming Audio Quality 

6.5.7.1 Abstract Definition 

The parameter Streaming Audio Quality describes the audio quality as perceived by the end-user. Since the streams can 
contain and not only speech information, an algorithm like P. 862 is not suitable for all scenarios. 

ITU-R has defined an algorithm defined for audio information. It can be found in [6]. 

6.5.7.2 Abstract Equation 

To be defined. 



6.5.7.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Tbd 


Start: Begin of audio stream 
reproduction. 


Start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


Stop: End of audio stream 
reproduction. 


Stop: RTSP: TEARDOWN. 



6.5.8 Streaming Video Quality 

6.5.8.1 Abstract Definition 

The parameter Streaming Video Quality measures the quality of the video stream. 

NOTE 1 : Although evaluation algorithms exist, there are no standardized solutions yet. 

NOTE 2: Standardization process of evaluation algorithms is on-going and new reconmiendations are expected 
during the ITU study period 2005-2008. 

6.5.8.2 Abstract Equation 

NOTE 1 : Although evaluation algorithms exist, there are no standardized solutions yet. 

NOTE 2: Standardization process of evaluation algorithms is on-going and new recommendations are expected 
during the ITU study period 2005-2008. 
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6.5.8.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Tbd 


Start: Begin of video stream 
reproduction. 


Start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


Stop: End of video stream 
reproduction. 


Stop: RTSP: TEARDOWN. 



6.5.9 Streaming Audio/Video De-Synchronization 

6.5.9.1 Abstract Definition 

The parameter Streaming AudioA'^ideo De-Synchronization describes the percentage of times that time difference of the 
audio and video signal at the user side exceeds a predefined threshold. 

6.5.9.2 Abstract Equation 

No validated or standardized algorithm has been selected for the evaluation for video streaming content quality. 

6.5.9.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Tbd 


Start: Begin of audio stream 
reproduction. 


Start: Streaming players signal when the 
reproduction of the stream starts. 


Tbd 


Stop: End of audio stream 
reproduction. 


Stop: RTSP: TEARDOWN. 



6.5.10 Streaming Reproduction Start Failure Ratio [%] 

6.5.1 0.1 Abstract Definition 

The parameter Streaming Reproduction Start Failure Ratio describes the probabihty of unsuccessful stream 
reproduction. 

NOTE: This parameter can be affected: 

■ by the player; 

■ by the UE performance. 

6.5.1 0.2 Abstract Equation 



Streaming Reproduction Start Failure Ratio [%] = 



reproduction failures 
all successful service accesses 



-xlOO 



6.5.10.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Service access attempt 


Start: "Buffering" message. 


Start: Reception of first data packet. 


Successful reproduction 


Stop: Stream reproduction. 


Stop: Streaming players signal when the 
reproduction of the stream starts. 


Unsuccessful reproduction 


Stop trigger point not reached. 
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6.5.1 1 Streaming Reproduction Start Delay [s] 
6.5.1 1 .1 Abstract Definition 

The parameter Streaming Reproduction Delay describes the duration between the reception at UE of the first stream 
data packet and the start of the reproduction of the stream on the UE. 

NOTE: This parameter can be affected: 

■ by the player; 

■ by the UE performance. 



6.5.1 1 .2 Abstract Equation 

Streaming Reproduction Start Delay [S] = (tstartof streamreproduction - treceptionof firstdatapacket)[s] 



6.5.11.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


deception of first data packet 


Start: "Buffering" message. 


Start: Reception of first data packet. 


^start of stream reproduction 


stop: Stream reproduction. 


Stop: Streaming players signal when the 
reproduction of the stream starts. 



6.5.12 Streaming Teardown Failure Ratio [%] 
6.5.12.1 Abstract Definition 

The parameter Teardown Failure Ratio describes the probability that the "Teardown" RTSP message is sent from the 
UE client to the server and no "200 OK" RTSP response is received from the server. 



6.5.12.2 Abstract Equation 



Teardown Failure Ratio [%] = 



cases without teardown server response 
all teeirdown attempts by UE client 



xlOO 



6.5.12.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Teardown attempt 


Start: User presses the "Stop" 
button. 


Start: RTSP: TEARDOWN. 


Successful Teardown 


Stop: Stream is torn down. 


Stop: RTSP: 200 OK. 


Unsuccessful Teardown 


Stop trigger point not reached. 



Some players do not send this TEARDOWN command at the end of the stream but a PAUSE conmiand or in some 
cases nothing at all. On the server side a logic can then identify the status of the streams/clients. 

Used players should send the RTSP:TEARDOWN command in order to give a stable trigger point for measurements. 
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6.5.13 streaming Teardown Time [s] 

6.5.13.1 Abstract Definition 

The parameter Teardown Failure Ratio describes the duration between the UE client sending the "Teardown" RTSP 
message and the "200 OK" RTSP response from the server. 

6.5.1 3.2 Abstract Equation 



Teardown Time [S] (t server repsonse to teardown message " ^UE client sending teardown message ) 1-^] 



6.5.13.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^UE client sending teardown message 


Start: User presses the "Stop" 
button. 


Start: RTSP: TEARDOWN. 


^server response to teardown message 


Stop: Stream is torn down. 


Stop: RTSP: 200 OK. 



Some players do not send this TEARDOWN command at the end of the stream but a PAUSE conmiand or in some 
cases nothing at all. On the server side a logic can then identify the status of the streams/clients. 

Used players should send the RTSPiTEARDOWN conmiand in order to give a stable trigger point for measurements. 

6.5.14 Streaming Rebuffering Failure Ratio [%] 

6.5.14.1 Abstract Definition 

The parameter Rebuffering Failure Ratio describes the probability that a stream goes into rebuffering mode and does 
not restart the stream reproduction, afterwards. 

6.5.14.2 Abstract Equation 



Rebuffering Failure Ratio [%] = 



unsuccessful rebuffering attempts 
all rebuffering attempts 



xlOO 



6.5.14.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Teclinical description/protocol part 


Rebuffering attempt 


Start: "Buffering" message 
appears. 


Start: Streaming player signals the start of the 
stream buffering. 


Successful continuation of 
reproduction 


Stop: Stream reproduction 
continues. 


Stop: Streaming player signals the continuation 
of the stream reproduction. 


Unsuccessful continuation of 
reproduction 


Stop trigger point not reached. 



6.5.15 Streaming Rebuffering Time [s] 
6.5.15.1 Abstract Definition 



The parameter Rebuffering Time describes the duration between a stream going into rebuffering mode and continuation 
of the stream, afterwards. 
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6.5.1 5.2 Abstract Equation 



Rebuff ering Time[s] — (t^ontinuation of stream " trebufferingmessageappears/t^] 



6.5.15.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Vebuffering message appears 


Start: "Buffering" message 
appears. 


Start: Streaming player signals the start of the 
stream buffering. 


^continuation of stream 


Stop: Stream reproduction 
continues. 


Stop: Streaming player signals the continuation 
of the stream reproduction. 



6.6 Telephony 

6.6.1 Telephony Service Non-Accessibility [%] 

6.6.1.1 Abstract Definition 

The telephony service non-accessibility denotes the probability that the end-user cannot access the mobile telephony 
service when requested if it is offered by display of the network indicator on the UE. 

NOTE: Due to network problems and despite B -party being not busy (see preconditions for measurement), it may 
even be possible for the A-party to receive a busy or not reachable signal. In this case, since no 
ALERTING message will be sent, the test sample will be treated as a failure. 

6.6.1 .2 Abstract Equation 



1 1 • ^ -i -i- unsucccssful Call attcmpts 

Telephony Service Non - Accessibility [%] = — xlOO 

all call attempts 



6.6.1.3 Trigger Points 



GSM: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Gall attempt 


Start: Push Send button. 


Start: 

Layer 3 (RR): The "CHANNEL REQUEST" message is 
sent over the RACH. 


Successful call attempt 


Stop: Alerting tone is heard 
by the A-party 

AND 

B-party rings. 


Stop: 

Layer 3 (CC): The "ALERTING" message is passed: 

1 . from the B-party to the MSG (uplink) 

AND 

2. from the MSG to the A-party (downlink) to indicate 
that the B-party rings. 


Unsuccessful data call 
access 


Stop trigger point not reached. 
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UMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Call attempt 


Start: 

Push Send button. 


Start: 

Layer 3 (RRC): The first "RRC CONNECTION 
REQUEST" with Establishment Cause "Originating 
Conversational Call" message carried on the CCCH 
logical channel and mapped to the RACH transport 
channel is sent. 

(Figure 23; signalling point number 1). 

Comment: It is possible that the RRC connection is 
already established because of an e.g. Location 
Update, then the start trigger is not reachable. In this 
case the current test sample should be deleted. 


Successful call 
attempt 


Stop: 

Alerting tone is heard by the 
A-party 

AND 

B-party rings. 


Stop: 

Layer 3 (CC): The "ALERTING" message is passed: 

1 . from the B-party to the MSC (uplink) 

AND 

2. from the MSC to the A-party (downlink) to 
indicate that the B-party rings. 

(Figure 23; signalling point number 44). 


Unsuccessful call 
attempt 


Stop trigger point not reached. 


NOTE: With automatic tools there is not a significant difference between consider the "ALERTING" or the 
"CONNECT" message, as the answer machine should always answer immediately. 



TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Call attempt 


Start: Push Send button. 


Start: 

Layer 3 (CMCE): The "U-SETUP" message with 
appropriate signalling information is sent from the A-party. 

AT: The "ATD <dial string>" command is sent from the 
A-party, where <dial string> provides a unique 
identification of the desired B-party side. A preceding 
"AT+CTSDC" command is used to set the correct 
parameters for the dial command. 


Successful call attempt 


Stop: Alerting tone is heard 
by the A-party 

AND 

B-party rings. 


Stop: 

Layers (CMCE): 

1 . the "U-ALERT" message is passed from the B-party to 
the SwMI (uplink) 

AND 

2. the "D-ALERT" message is passed from the SwMI to the 
A-party (downlink) to indicate that the B-party rings. 

AT: The "ATA" command is sent by the B-party upon 
reception of the ring indication and the "AT+CTOCP: <CC 
instance>, <call status>, ..." with <call status> = 2 (Called 
party paged) indication is received by the A-party to 
indicate that the B-party rings. 


Unsuccessful call attempt 


Stop trigger point not reached within desired time. 


NOTE: The described technical trigger points are valid for measurements with hook signalling enabled. In case 

direct signalling is used for the call establishment procedure the relevant air interface protocol messages for 
the stop trigger are "U-CONNECT" and "D-CONNECT" (instead of "U-ALERT and "D-ALERT"), respectively. 
It shall be clearly stated which call establishment method is used for the telephony measurements. 
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Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






B-party shall not be busy 







UE 


J 







Node B 



. RACH: CCCH: RRC CONNECTION REOUEST <TM> 




2. RADIO LINK SETUP REQUEST 



3. RADIO LINK SETUP RESPONSE 



. ESTABLISH REOUEST (AAL2) 



5. ESTABLISH CONFIRM (AAL2) 



6. DOWNLINK SYNCHRONISATION 



7. UPLINK SYNCHRONISATION 



!. FACH: CCCH: RRC CONNECTION SETUP <UM> 



9. INSYNCH IND 




10. RADIO LINK RESTORE INDICATION , 



11. DCCH: RRC CONNECTION SETUP COMPLETE <AM> 



RNC 






MSC/VLR MGW 



UE 





NodeB 



12. DCCH: INITIAL DT [ CM SERVICE REQUEST] <AM> 



17. DCCH: SECURITY MODE COMMAND <AM> 



18. DCCH: SECURITY MODE COMPLETE <AM> 



21 . DCCH: DLDT [ IDENTITY REOUEST ] <AM> (IMEI) 



22. DCCH: ULDT [ IDENTITY RESPONSE ] <AM> (IMEI) 



24. DCCH: ULDT [ SETUP ] <AM> 



28. DCCH: DLDT [ GALL PROCEEDING ] <AM> 



RNC 



MSC/VLR 



13. SCCP CONNECTION RO [ 

INITIAL UE MESSAGE 
[CM SERVICE REOUEST]] 



14. SCCP CONNECTION 
CONFIRM 



15. COMMON ID 



16. SECURITY MODE COMMAND 



19. SECURITY MODE COMPLETE 






27. DT [ CALL PROCEEDING ] 
[^RANAP^H QRANAPJ) 



MGW 
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UE 



NodeB 




33. RADIO LINK RECONFIG PREPARE 



34. RADIO LINK RECONFIG READY 



35. ESTABLISH REOUEST (AAL2) 



36. ESTABLISH CONFIRM (AAL2) 



37. RADIO LINK RECONFIG COMMIT 



38. DCCH: RADIO BEARER SETUP <AM> 



40. DCCH: RADIO BEARER SETUP COMPLETE <AM> 



44. DCCH: DLDT [ ALERTING ] <AM> 




47. DCCH: DLDT [ CONNECT ] <AM> 



49. DCCH: ULDT [ CONNECT ACK ] <AM> 



RNC 




MSC/VLR 



30. RAB ASSIGNMENT REQUEST 



MGW 



29. BINDING ID, SPEECH 
CODEC TYPE, B PARTY 
^ ROyT.E J 



31 . ESTABLISH REOUEST ( AAL2 ) 



32. ESTABLISH CONFIRM ( AAL2 



39. RAB ASSIGNMENT RESPONSE 



43. DT [ ALERTING ] 



50. DT[ CONNECT ACK] 




ALCAP^ 

^"alcap^^ 



48. OPEN 
CONNECTION 



Figure 23: 3G telephony signalling flow chart: mobile originated call establishment procedure 
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UE 



RRC 
RRC 



Node B 



51. DCCH: ULDT [ DISCONNECT ] <AM> 



55. DCCH: DLDT [ RELEASE ] <AM> 



56. DCCH: ULDT [ RELEASE COMPLETi ] <AM> 



60. DCCH: RADIO BEARER RELEASE <UM> 



64. DCCH: RADIO BEARER RELEASE COMPLETE <UM> 



65. DCCH: RRC CONNECTION RELEASE <UM> 



RNC 



52. DT [ DISCONNECT ] 



54. DT [ RELEASE ] 



61 . RELEASE REOUEST ( AAL^ ) 



62. RELEASE CONFIRM ( AAL2 ) 



RRc^ ) Quick Repeat 




UE 



NodeB 



). DCCH: RRC CONNECTION RELEASE COMPLETE <UM> 



RNC 







67. SCCP RELEASED 



MSC/VLR 







MGW 



^ 71. RADIO LINK DELETION REQUEST ^ 
NBAPJH — C NBAP 



72. RADIO LINK DELETION RESPONSE 
' NBAP ') NBAP 



73. RELEASE REOUEST( AAL2 ) 
" ALCAP C ALCAP 



74. RELEASE REOUEST ( AAL2 ) 
' ALCAP >^ ■ C ALCAP 



75. RELEASE CONFIRM ( AAL2 ) 
" ALCAP ^ ►C ALCAP 



76. RELEASE CONFIRM ( AAL2 ) 
' ALCAP ^ K ALCAP 




(^ JSUP^ ))^ 



Figure 24: 3G telephony signalling flow chart: mobile initiated call disconnection procedure 
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tncD_5elTUEi req 


U- SETUP ^ 


rrle_unitda& req ^ 


Start T3fl3 
tnM;_jj«K*ed ind 


^ report ind 


^ nrle_reDort ind 


nQFinrf inrl 
^ 1 cpui L iriu 


^ nrle_re sort ind 


^ FTEportind 


^ nrle_report ind 


D-GALL 


^mle_unitdata ind 


^ nil£_uni)da[ta nd 


PROCEEDING 
^ D-INFO 


Stop T3u3 
Start 7302 

^Uicc notify ind 


^mle_unitdata ind 


^ D-ALERT 


* |Star4T3C12) 
_1nicc_-alert ind 


^mle_unrtdaEa ind 


^ D-CONNECT 


* Start 13(12 
. Ifwc sdiipcxsn 


mle_coiifigura- req^ 


conngune neq ^ 


^ StSpYi^ 

Start T31# 







Tife_unitd3t3 ind ^ 


□-SETUP ^ 


5tntK_5etup ind ^ 






. mle iMirtdata req 


^ y-ALERT 


^ Incc_setup_re5- 


^ t" oe_ccimplete rec 


report ind ^ 


4i " =^ 

in le_nepcirt ind ^ 


in lE_nspDft ind ^ 


rrr|AJI L IIH ^ 


irilc l^rfJUILIIH ^ 


report ind 


^ iiile_unild3ta neq 


^ U^ONNECT 


Start T301 
tncc_complEDe con^ 


rBEKHrtind 


mle_rEpcirt ind ^ 


Mile cjJv 1 IIIU ^ 


r — _ ^ 

report ind ^ 


mle_'epcn ind ^ 


report ind ^ 


mle unrtdHta. ind ^ 


D-CONNECT 


^mle_Donngune ne<^ 


ACKNOWI^DGE^ 
^ configurE req 


StopT301 ^ 
Start T310 







Figure 25: Individual call set-up using on/off hook signalling (EN 300 392-2 [27], clause 14.5.1) 
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^ report hd 
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^ PROCEEDING 
^ D-CONNECT 
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Start T302 
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mle unitdata hd , 
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mfe urMtdata ind , 
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D-SETUP 



U-CO,NNECT 



rep<}rt ind 
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D-CONNECT 



ACKNOWLEDGE 
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Figure 26: Individual call set-up using direct set-up signalling (EN 300 392-2 [27], clause 14.5.1) 
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6.6.2 Telephony Setup Time [s] 

6.6.2.1 Abstract Definition 

The telephony setup time describes the time period between sending of complete address information and receipt of call 
set-up notification. 

6.6.2.2 Abstract Equation 



Telephony Setup Time [S] = (teo„„ec,establishal " tuserpressessendbuttononUE)[s] 



NOTE: This parameter is not calculated unless the telephony call setup attempt is successful. It is assumed that 
early traffic channel assignment is used. 



6.6.2.3 Trigger Points 

GSM: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^user presses send button on UE' 

Time of call attempt 


Start: Push Send button. 


Start: 

Layer 3 (RR): The "CHANNEL REQUEST" message is 
sent over the RACH. 


^connection establislied" "'"''^^ 

when connection is 
established (successful call 
attempt) 


Stop: Alerting tone is heard 
by the A-party 

AND 

B-party rings. 


Stop: 

Layer 3 (CC): The "ALERTING" message is passed: 

1 . from the B-party to the MSG (uplink) 

AND 

2. from the MSG to the A-party (downlink) to indicate 
that the B-party rings. 



UMTS: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^user presses send button on UE' 

of call attempt 


Start: 

Push send button. 


Start: 

Layer 3 (RRG): The first "RRG GONNEGTION 
REQUEST" with Establishment Gause 
"Originating Gonversational Gall" message 
carried on the GGGH logical channel and 
mapped to the RAGH transport channel is sent. 
(Figure 23; signalling point number 1). 

Gomment: It is possible that the RRG 
connection is already established because of an 
e.g. Location Update, then the start trigger is 
not reachable. In this case the current test 
sample should be deleted. 


^connection established" 

connection is established 
(successful call attempt) 


Stop: 

Alerting tone is heard by the 
A-party 

AND 

B-party rings. 


Stop: 

Layer 3 (CC): The "ALERTING" message is 
passed: 

1 . from the B-party to the MSG (uplink) 

AND 

2. from the MSG to the A-party (downlink) 
to indicate that the B-party rings. 

(Figure 23; signalling point number 44). 


NOTE: With automatic tools there is not a significant difference between consider the "ALERTING" or the 
"GONNEGT" message, as the answer machine should always answer immediately. 
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TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^user presses send button on UE- 

Time of call attempt 


Start: Push Send button. 


Start: 

Layer 3 (CMCE): The "U-SETUP" message with 
appropriate signalling information is sent from the A-party. 

AT: The "ATD <dial string>" command is sent from the 
A-party, where <dial string> provides a unique 
identification of the desired B-party side. A preceding 
"AT+CTSDC" command is used to set the correct 
parameters for the dial command. 


^connection established" "'"''^^ 

when connection is 
established (successful call 
attempt) 


Stop: Alerting tone is heard 
by the A-party 

AND 

B-party rings. 


Stop: 

Layers (CMCE): 

1 . the "U-ALERT" message is passed from the B-party to 
the SwMI (uplink) 

AND 

2. the "D-ALERT" message is passed from the SwMI to the 
A-party (downlink) to indicate that the B-party rings. 

AT: The "ATA" command is sent by the B-party upon 
reception of the ring indication and the "AT+CTOCP: <CC 
instance>, <call status>, ..." with <call status> = 2 (Called 
party paged) indication is received by the A-party to 
indicate that the B-party rings. 


Unsuccessful call attempt 


Stop trigger point not reached. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






CS service access successful 


Telephony Service Non-Accessibility 





6.6.3 Telephony Speech Quality on Call Basis 

6.6.3.1 Abstract Definition 

The telephony speech quaUty on call basis is an indicator representing the quantification of the end-to-end speech 
transmission quality of the mobile telephony service. This parameter computes the speech quality on the basis of 
completed calls. 

NOTE: The acoustic behaviour of terminals is not part of this speech quality measurement. 

6.6.3.2 Abstract Equation 

The validation of the end-to-end quality is made using MOS-LQO scales. These scales describe the opinion of users 
with speech transmission and its troubles (noise, robot voice, echo, dropouts, etc.) according to 
ITU-T Recommendation P.862 [1] in conjunction with ITU-T Recommendation P.862.1 [9],or according to ITU-T 
Recommendation P. 863 [31]. The algorithm used should be reported. The speech quality measurement is taken per call. 
An aggregation should be made on one value for speech quality per call. 



Telephony Speech Quality on Call Basis (received A - party) = f (MOS - LQO) 
Telephony Speech Quality on Call Basis (received B - party) = f (MOS - LQO) 



Optionally it might be useful to aggregate both speech quality values into one. In this case the worst of both shall be 
used. This aggregated speech quality value shall be called SpQ (min). 
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6.6.3.3 Trigger Points 

GSM/UMTS: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Not applicable. 


Start: 

Interchange speech samples 
between A-party and B-party. 


Start: 

Layer 3 (CC): The "CONNECT" message on the 
DCCH logical channel is passed from the MSC 
to the UE to indicate that the called user's end 
has been connected. 
(Figure 23; signalling point number 47). 


Not applicable. 


Stop: 

Release of connection. 


Stop: 

Layer 3 (CC): The "DISCONNECT" message on 
the DCCH logical channel is intentionally sent 
from the UE (message sent when the user ends 
the call). 

(Figure 24; signalling point number 51 ). 



TETRA: 

The applicability of a suitable speech quality evaluation method for the narrow-band speech codec within TETRA 
networks is for further study. 

6.6.4 Telephony Speech Quality on Sample Basis 

6.6.4.1 Abstract Definition 

The telephony speech quality on call basis is an indicator representing the quantification of the end-to-end speech 
transmission quality of the mobile telephony service. This parameter computes the speech quality on a sample basis. 

NOTE: The acoustic behaviour of terminals is not part of this speech quality measurement. 

6.6.4.2 Abstract Equation 

The validation of the end-to-end quality is made using MOS-LQO scales. These scales describe the opinion of users 
with speech transmission and its troubles (noise, robot voice, echo, dropouts, etc.) according to 
ITU-T Reconmiendation P. 862 [1] in conjunction with ITU-T Reconmiendation P. 862.1 [9], or according to ITU-T 
Reconmiendation P. 863 [31]. The algorithm used should be reported. The speech quality measurement is taken per 
sample. An aggregation for measurement campaigns or parts of it should be made on speech sample basis. 

Telephony Speech Quality on Sample Basis (received A - party) = MOS - LQO 
Telephony Speech Quality on Sample Basis (received B - party) = MOS - LQO 

Optionally it might be useful to aggregate both speech quality values into one. In this case the worst of both shall be 
used. This aggregated speech quality value shall be called SpQ (min). 

6.6.4.3 Trigger Points 

The same as for speech quality on call basis (see clause 6.6.3.3). 

6.6.5 Telephony Cut-off Call Ratio [%] 
6.6.5.1 Abstract Definition 

The telephony cut-off call ratio denotes the probability that a successful call attempt is ended by a cause other than the 
intentional termination by A- or B-party. 
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6.6.5.2 Abstract Equation 



, ^ ^ 11 . umntentionallv terminated telephonv calls 

Telephony Cut - off Call Ratio [%] = x 1 00 

all successful telephony call attempts 



6.6.5.3 Trigger Points 



GSM/UMTS: 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful telephony call attempt 


Start: 

Alerting tone heard by the A-party 
coming from B-party. 


Start: 

Layers (CC): The "CONNECT" message on the 
DCCH logical channel is passed from the MSC 
to the UE to indicate that the connection has 
been established. 

(Figure 23; signalling point number 47). (See 
note). 


Intentionally terminated 
telephony call 


Stop: 

Release of connection directly by 
A- or B-party. 


Stop: 

Layers (CC): The "DISCONNECT" message on 
the DCCH logical channel is intentionally sent 
from the UE (message sent when the user ends 
the call). 

(Figure 24; signalling point number 51 ). 


Unintentionally terminated 
telephony call 


Stop trigger point not reached. 


NOTE: With automatic tools there is not a significant difference between consider the alerting or the connect 
message, as the answer machine should always answer immediately. 



TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful telephony call 
attempt 


Start: Connect indication 
received at originating 
A-party side. 


Start: 

Layer 3 (CMCE): The "D-CONNECT" message is received 
at the A-party to indicate that the called user's end has 
been connected. 

AT: The "AT+CTCC" indication is received by the A-party 
to indicate that the called user's end has been connected. 


Intentionally terminated 
telephony call 


Stop: Release of connection 
directly by A- or B-party. 


Stop: 

Layer 3 (CMCE): The "U-DISCONNECT" message with 
disconnect cause "User requested disconnect" is sent from 
either A-party or B-party UE (message sent when the user 
ends the call). 

AT: The "ATH" command is sent by either A-party or 
B-party (message sent when the user ends the call). 


Unintentionally terminated 
telephony call 


Stop trigger point not reached. 
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6.6.6 Telephony CLIP Failure Ratio [%] 



6.6.6.1 Abstract Definition 

The telephony CLIP failure ratio denotes the percentage of call setups where a valid calling party number (CPN) 
parameter was sent but not received intact. 

NOTE: To conform to legal request the calling line identity (CLI) may be suppressed in some (roaming) cases, 
taking into account that a roamed call may consist of two independent call legs. 

6.6.6.2 Abstract Equation 



Telephony CLIP Failure Ratio [%] = 

number of calls received by B - party without intact CPN 
number of calls offered by A - party with valid CPN 



xlOO 



6.6.6.3 Trigger Points 



GSM: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Calls offered by A-party with 
valid CPN 


Start: 

Push send button at the 
A-party (calling party). 


Start: 

Layer 3 (RR): The "CHANNEL REQUEST" message is sent 
by the UE over the RACH. 


Calls received by B-party 
without intact CPN 


stop: 

No presentation or 
presentation of invalid calling 
number on the display of the 
B-party mobile. 


Stop: 

Layer 3 (CC): The "SETUP" message without valid calling 
party (A-party) number is received by the B-party. 



UMTS: 



Event from abstract 
equation 


Trigger point from user's point of 
view 


Technical description / protocol part 


Calls offered by A-party 
with valid CPN 


Start: 

Push send button at the A-party 
(calling party). 


Start: 

Layer 3 (RRC): The first "RRC CONNECTION 
REQUEST" message with establishment cause 
"Originating Conversational Call" message carried on 
the CCCH logical channel and mapped to the RACH 
transport channel is sent. (Figure 23: signalling point 
number 1) 

Comment: It is possible that the RRC connection is 
already established because of an e.g. Location 
Update, then the start trigger is not reachable. In this 
case the current test sample should be deleted. 


Calls received by B-party 
without intact CPN 


Stop: 

No presentation or presentation of 
invalid calling number on the display 
of the B-party mobile. 


Stop: 

Layer 3 (CC): The "SETUP" message without valid 
calling party (A-party) number is received by the 
B-party. 
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TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Calls offered by A-party with 
valid CPN 


Start: 

Push send button at the 
A-party (calling party). 


Start: 

Layer 3 (CMCE): The "U-SETUP" message with 
appropriate signalling information is sent from the A-party. 


Calls received by B-party 
without intact CPN 


Stop: 

No presentation or 
presentation of invalid calling 
number on the display of the 
B-party mobile. 


Stop: 

Layer 3 (CMCE): The "D-SETUP" message without valid 
calling party (A-party) number (calling party identifier) is 
received by the B-party. 



6.7 Video Telephony 

6.7.1 Network Accessibility/Availability 

Network availability and network accessibility are measured independently from the service, and will not be described 
further in this clause. Network availability and network accessibility are pre-conditions for the performance of the 
measurement of QoS. 

6.7.2 Parameter Overview Chart 

To get a better overview of the following parameters, Figure 27 shows all steps of a Video Telephony call from origin 
to destination, and the related QoS parameters. 

Preconditions for the measurements: It should be a bi-directional Video Telephony call. Both sides should allow the 
transmission of both audio and video. 

Explanation: The upper half considers the trigger points and parameters at the originated side and the lower half at the 
terminated side. The rectangles are connected to the trigger points that are relevant for analysis. For example: "t3, orig. 
side" (triggerpoint at originated side) and "t3, term, side" (triggerpoint at terminated side) are points of time that 
describe a similar event but it could be passed at slightly different times. The preconditions are specified in brackets 
behind the parameter name. The technical triggers are defined for positive successful cases, if the VT works fine. For 
failures the triggers are the opposite, this means the non-existence of the message indicates the failure. The bold lines 
behind the trigger points tx are the used one and the dashed one are unused. 
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VT Cut-off Call Ratio [%] , (Precond.: Service Access) . 



mobile 
originated side 



I 



parameters 



VT Service Non- 
Accessibility [%] 



trigger points 
customer's 
view 



teclinical 
trigger points 
for success 
cases 



VT Service Access 
Time [s] , (Precond.: 
Service Access) 

presses connect 
button (originated 
side) 



RRC CONNECTION 
REQUEST message 
(CCCH ) 

to, orig. side 




hears a) alerting or b) 
busy tone 



ALERTING (DCCH), 

(between 

RNC>UE(MO)) 

t1 , orig. side 



t1 , term, side 

ALERTING (DCCH), 

(between 

UE(MT)>RNC) 



VT Audio/Video Setup 
Failure Ratio [%] , 
(Precond.: Service 
Access) 



VT Audio/Video Setup; 
Time [s] , (Precond 
Service Access) 



seeing call accept 



CONNECT message 
(DCCH ), (between 
RNC>UE(MO)) 

t2, term, side 



hears mobile ringing 
tone (in case of a) s. 
originated) 



t2, term, side 

ICONNECT message 
|(DCCH ), (between 
IuE(MT)>RNC) 

[accepting call 
■(terminated side) 



VT Audio/Video Setup| 
Time [s] , (Precond 
Service Access) 



sees/hears 
established 
video/audio 



reception of audio and 
video data from the 
other side 

t3, orig. side 



VT End-To-End Mean 

One-Way 
Transmission Time [s] 
, (Precond.: A/V 

audio / video data 
UPLINK 



t3, term, side 



reception of audio and 
video data from the 
other side 




sees/hears 
established 
video/audio 



audio / video data 
UPLINK 

VT End-To-End Mean 

One-Way 
Transmission Time [s] 
, (Precond.: A/V 



VT Audio/Video Setupj 
Failure Ratio [%] , 
(Precond.: Service 
Access) 



VT Cut-off Call Ratio [%] , (Precond.: Service Access) 

Figure 27: Parameter overview with trigger points 



VT Audio Quality 
[MOS-LQO] , 
(Precond.: A/V Setup) 



VT Video Quality , 

(Precond.: Call 
Setup), (Precond.: 
A/V Setup) 



VT Audio/Video Sync. 
[%] , (Precond.: A/V 
Setup) 



audio / video data 
DOWNLINK 



continuous reception 
of audio and video 
data at both sides 
from the opposite side 



t5, orig. side 



t5, term, side 
continuous reception 
of audio and video 
data at both sides 
from the opposite side 



audio / video data 
DOWNLINK 



VT Audio/Video Sync. 
[%] , (Precond.: A/V 
Setup) 



VT Video Quality , 
(Precond.: A/V Setup) 



VT Audio Quality 
[MOS-LQO] , 
(Precond.: A/V Setup) 



intentiona termination 



continuous reception 
of audio and video 
until int. termination 

t6a, orig. side 



t6a, term, side 

continuous reception 
of audio and video 
until int. termination 



END 
SESSIO 
N (H.245) 

t6b, orig. side 



END 
SESSIO 
N (H.245) 



intentiona termination 



of call 



If MO releases the 
call: DISCONNECT,- 
RELEASE 

combination I 
t6c, orig. side 



t6b, term. side|t6c, term, side 

If MT releases the 
call: DISCONNECT, 
RELEASE 
combination 



of call 
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6.7.3 VT Service Non-Accessibility [%] 

6.7.3.1 Abstract Definition 

Probability that the end-user cannot access the service when requested while it is offered by network indication on the 
mobile equipment. 

NOTE: Due to network problems and despite MO side being not busy (see preconditions for measurement), it 
may even be possible for the MO side to receive a busy or not reachable signal. In this case, since no 
ALERTING message will be sent, the test sample will be treated as a failure. 

6.7.3.2 Abstract Equation 



. ..T A .1.1. unsuccessful video telephony call access attempts 

VT Service Non - Accessibility [%] = ^xlOO 

all video telephony call access attempts 



6.7.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Video Telephony call 
attempt 


Start: Push Send button. 


Start: The first RRC CONNECTION REQUEST with 
Establishment Cause „originating conversational call 
message carried on the CCCH logical channel and 
mapped to the RACH transport channel is sent. 
(Figure 28, signalling point number 1). 

Comment: It is possible that more than one RRC 
CONNECTION REQUEST message per call attempt is 
sent. Only the first RRC CONNECTION REQUEST with 
Establishment Cause ..Originating Conversational Call 
should be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location Update, then the 
start trigger is not reachable. In this case the current test 
sample should be deleted. 


Successful Video 
Telephony call attempt 


Stop: Alerting tone is heard by the MO 
side coming from the MT side 

AND 

MT side rings. 


Stop: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at MT side to MSC (uplink) 
AND 

2. from the MSC to the UE at MO side (downlink) to 
indicate that the MT side rings. 

(Figure 28, signalling point number 44). 


Unsuccessful Video 
Telephony call attempt 


Stop trigger point not reached. 


Stop trigger point not reached. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






MT side shall not be busy 
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6.7.4 VT Service Access Time [s] 

6.7.4.1 Abstract Definition 

Time between pushing send button after input of MSISDN and receipt of alerting at MO side. 
Remark: 

• This parameter is not calculated unless the video telephony call access attempt is successful. At MT side the 
mobile shall ring. 

6.7.4.2 Abstract Equation 

VT Service AccessTime [s] = (t^iertingtone - tpush send button 



6.7.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Vush send button" 

of Video Telephony 
call attempt 


Start: Push Send button. 


Start: The first RRC CONNECTION REQUEST with 
Establishment Cause ..originating conversational call 
message carried on the CCCH logical channel and 
mapped to the RACH transport channel is sent. 
(Figure 28, signalling point number 1). 

Comment: It is possible that more than one RRC 
CONNECTION REQUEST message per call attempt is 
sent. Only the first RRC CONNECTION REQUEST with 
Establishment Cause „Originating Conversational Call 
should be taken into account for the calculation. 

It is possible that the RRC connection is already 
established because of an e.g. Location Update, then the 
start trigger is not reachable. In this case the current test 
sample should be deleted. 


Wrtingtone^Time Of 

successful Video 
Telephony call attempt 


stop: Alerting tone is heard by the MO 
side coming from the MT side 

AND 

MT side rings. 


Stop: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at MT side to MSC (uplink) 
AND 

2. from the MSC to the UE at MO side (downlink) to 
indicate that the MT side rings. 

(Figure 28, signalling point number 44). 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access 


VT Service Access Failure Ratio 
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6.7.5 VT Audio/Video Setup Failure Ratio [%] 
6.7.5.1 Abstract Definition 

Probability of audio/video setup failure after service access. The audio/video setup is successful if audio and video 
output is performed at both sides. 

Remarks: 

• This parameter reports a failure if the end-trigger is not reached at both sides. 

• This parameter is not calculated unless the VT service access attempt is successful. 

• This parameter depends on the mobile used and on the multimedia protocol stack implemented (e.g. answer 
fast feature). 



6.7.5.2 Abstract Equation 



VT Audio/Video Setup Failure Ratio [%] = 



audio/video setup failures 
all accepted calls at MT side 



xlOO 



6.7.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Audio/video setup 
attempt 


Start: MO sees the call acceptance 
from the MT side. 


Start: The CONNECT message on the DCCH logical 
channel is passed from the MSC to the UE at MO side to 
indicate that the connection has been established. 
(Figure 28, signalling point number 47) 


Audio/Video Setup 
Success 


Stop: Start of the audio and video 
output at both sides. 


Stop: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


Audio/Video Setup 
Failure 


Stop trigger point not reached. 


Stop trigger point not reached. 



Preconditions of measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access 
successful 


VT Service Non-Accessibility 





6.7.6 VT Audio/Video Setup Time [s] 
6.7.6.1 Abstract Definition 

The elapsed time from the MT call acceptance indicated at MO side until audio and video output starts at both sides. 
Remarks: 

• This parameter should report the worse time of both sides. 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• This parameter depends on the mobile used and on the multimedia protocol stack implemented (e.g. answer 
fast feature). 
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6.7.6.2 Abstract Equation 

VTAudiomdeO Setup Time [S] = (taudioMdeo start -tMTacceptscall)[s] 



6.7.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


W accepts call" 
beginning of 
audio/video setup 


Start: MO sees tlie call acceptance 
from the MT side. 


Start: The CONNECT message on the DCCH logical 
channel is passed from the MSC to the UE at MO side to 
indicate that the connection has been established. 
(Figure 28, signalling point number 47). 


^audio/video start" 

successful audio/video 
setup 


Stop: Start of the audio and video 
output at both sides. 


Stop: Start of reception of audio and video data at both 
sides from the opposite side + constant time value for 
decoding. 

Comment: All four data streams shall be received for a 
success. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure 
Ratio 





6.7.7 VT Cut-off Call Ratio [%] 

6.7.7.1 Abstract Definition 

Probability that a successful service access is ended by a cause other than the intentional termination of the user (calling 
or called party). 

Remark: 

• This parameter is not calculated unless the VT service access attempt is successful. A VT call is considered 
dropped: 

if the call acceptance fails after alerting; 
if audio/video setup fails; or 

if either the audio, the video or both are lost at one or both sides for an interruption timeout and before 
the end of "predefined call duration". 

The "predefined call duration" is the difference between the indication of the call acceptance at MO side and the 
intentional release of the call. 

6.7.7.2 Abstract Equation 



VT Cut - off Call Ratio [%] = video telephony dropped calls ^ 

all successful video telephony service access attempts 



ETSI 



119 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



6.7.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful Video 
Telephony service 
access attempt 


Start: Alerting tone is heard by the MO 
side conning from MT side 

AND 

MT side rings. 


Start: The ALERTING message on the DCCH logical 
channel is passed: 

1 . from the UE at MT side to MSG (uplink) 
AND 

2. from the MSG to the UE at MO side (downlink) to 
indicate that the MT side rings. 

(Figure 28, signalling point number 1). 


Video Telephony 
successful call 


Stop: No loss of video and/or audio 
without any intention by MO or MT side 
longer than the interruption timeout 
within the predefined call duration. 


Stop: 

1 . If the test system can capture audio/video information: 
Continuous reception of audio and video data at both 
sides from the opposite side without an interruption 
longer than the interruption timeout until intentional call 
release. 

2. If the test system cannot capture audio/video 
information: 

The following information shall not be seen in signalling 
before intentional call release but they shall be seen after 
the intentional call release: 

• H.245 EndSession command 
(endSessionCommand disconnect) 
OR 

• the following trigger combination (all triggers on 
the DCCH logical channel): 

[M1: DISCONNECT (uplink).] 
AND 

[M2: DISCONNECT (downlink) or RELEASE 
(downlink)] 
(Figure 28, signalling point number 51). 

Comment: In some cases the mobiles use not the 
EndSession command but only the DISCONNECT or 
RELEASE command. 


Video Telephony 
dropped calls 


Stop trigger point not reached. 


Stop trigger point not reached. 



If the reception of audio and/or video is interrupted shortly before the predefined call duration, then the call duration 
shall be extended to check if the interruption persists for the interruption timeout or not. If the interruption is shorter 
than the interruption timeout the call shall be released immediately and rated as success otherwise the sample shall be 
rated as failure and the call will be released. 

Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS GS attach successful 






UMTS CS service access successful 


VT Service Non-Accessibility 





6.7.8 VT Speech Quality on Call Basis 
6.7.8.1 Abstract Definition 

Indicator representing the quantification of the end-to-end speech transmission quality of the Video Telephony service. 
This parameter computes the speech quality on the basis of completed calls. 
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Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• The speech quality measurement is taken per call. An aggregation for measurement campaigns or parts of it 
should be made on speech sample basis. 

• The acoustic behaviour of terminals is not part of this audio quality measurement. The modelling of the 
acoustic part of the handset-terminals (e.g. frequency shaping) is incorporated in the speech quality assessment 
algorithm. Therefore the test mobiles used have to be connected at their electrical interfaces and not coupled 
acoustically, it has to be taken into account that a detailed way for insertion and capturing of audio signals is 
described in ITU-T Recommendation P.862.3 [19]. 

• For wideband (7 kHz) applications a standardized algorithm is available in ITU-T Reconmiendation 
P.862.2 [18]. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

• Experience has shown a high variable delay in video calls. 

• ITU-T Reconmiendation P.862 [1] is not approved for testing such video call applications. It has to be taken 
into account that further studies including auditory tests of video calls have to be conducted. 

6.7.8.2 Abstract Equation 

ITU-T Recommendation P.862 [1] (02/2001) together with the related mapping given in ITU-T Recommendation 
P.862. 1 [9] (10/2003) is recommended. This algorithm describes the opinion of users related to speech transmission 
quality (300 Hz through 3 400 Hz) and its connected impairments (background noise, unnatural voice, temporal 
clipping and interruptions, etc.). 

The speech quality measurement is taken per call (the evaluation algorithm is currently under study in ETSI STQ 
MOBILE WG) and per direction (DL at MO, DL at MT). 

After mapping the raw P.862 results according to ITU-T Recommendation P.862. 1 [9], the speech quality assessment is 
presented in a MOS-like scale between 1 and 5 called MOS Listening Quality Objective (MOS-LQO), as defined in 
ITU-T Recommendation P. 800.1 [23]. 



6.7.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful 
Audio/Video Setup 
Attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (only 
intentional) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 
• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 






UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure Ratio 
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6.7.9 VT Speech Quality on Sample Basis 



6.7.9.1 Abstract Definition 



Indicator representing the quantification of the end-to-end speech transmission quality as perceived by the user. This 
parameter computes the speech quahty on a sample basis. 

Remarks: 



• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Speech quality values from all video telephony calls should be taken into consideration for statistical quality 
analysis. 

• The speech quality measurement is taken per sample. An aggregation for measurement campaigns or parts of it 
should be made on speech sample basis. Only complete received samples of a dropped call are evaluable. 

• The acoustic behaviour of terminals is not part of this audio quality measurement. The modelling of the 
acoustic part of the handset-terminals (e.g. frequency shaping) is incorporated in the speech quality assessment 
algorithm. Therefore the test mobiles used have to be connected at their electrical interfaces and not coupled 
acoustically, it has to be taken into account that a detailed way for insertion and capturing of audio signals is 
described in the new ITU-T Recommendation P. 862.3 [19]. 

• For wideband (7 kHz) applications a standardized algorithm is available in ITU-T Recommendation 
P.862.2 [18]. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

• Experience has shown a high variable delay in video calls. 

• P.862 is not approved for testing such video call applications. It has to be taken into account that further 
studies including auditory tests of video calls have to be conducted. 



6.7.9.2 Abstract Equation 

VT Speech Quality on Sample Basis (received A - party) = IVLOS - LQO 
VT Speech Quality on Sample Basis (received B - party) = IVLOS - LQO 

ITU-T Recommendation P.862 [1] (02/2001) together with the related mapping given in ITU-T Reconmiendation 
P.862. 1 [9] (10/2003) is recommended. This algorithm describes the opinion of users related to speech transmission 
quality (300 Hz through 3 400 Hz) and its connected impairments (background noise, unnatural voice, temporal 
clipping and interruptions, etc.). 

The speech quality measurement is taken per sample and per direction (DL at MO, DL at MT). 

After mapping the raw P.862 results according to ITU-T Recommendation P.862. 1 [9], the speech quality assessment is 
presented in a MOS-like scale between 1 and 5 called MOS Listening Quality Objective (MOS-LQO), as defined in 
ITU-T Recommendation P. 800.1 [23]. 
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6.7.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful Audio/Video 
Setup Attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 


Attach Failure Ratio 




UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.10 VT Video Quality 

6.7.1 0.1 Abstract Definition 

End-to-end quality of the video signal as perceived by the end user during a VT call. This parameter computes the video 
quality on a sample basis. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Video quality values from all video telephony calls should be taken into consideration for statistical quality 
analysis. 

• The video quality measurement is taken per sample. An aggregation for measurement campaigns or parts of it 
should be made on video sample basis. Only complete received samples of a dropped call are evaluable. 

• Evaluation of a MO DL or MT DL and also for these both directions (sum) is possible by calculating the mean 
value of the results from all samples. 

6.7.1 0.2 Abstract Equation 

To be specified. 
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6.7.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer; 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 


Attach Failure Ratio 




UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.1 1 VT End-To-End Mean One-Way Transmission Time [s] 

6.7.1 1 .1 Abstract Definition 

Delay time from input of the signal at MS (MO/MT) (mic/cam) to output of the signal at MS (MT/MO) 
(loudspeaker/display) . 

Remark: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

6.7.1 1 .2 Abstract Equation 

Time from input of the signal at MS (MO/MT) to output at MS (MT/MO). 

Aggregation Algorithm: ((Transmission Time MO ->MT) + (Transmission Time MT->M0))/2. 

In case of a symmetrical channel one party could be configured as loopback device. The other one can determine the 
double delay by correlating transmit and receive signal. The delay should be measured after the loopback at the top of 
the radio bearer. 



As the delay of the codec is almost constant for a specific mobile implementation, the codec delay could be considered 
by a mobile depending offset. In each direction one shall add the encoder and the decoder times. For the whole 
loopback one shall calculate the following times: 



M0>MT 


Encoding of audio/video (slowest is used) 


a 




Transmission of audio/video (slowest is used) 


b 




Decoding of audio/video (slowest is used) 


c 


MT>M0 


Encoding of audio/video (slowest is used) 


d 




Transmission of audio/video (slowest is used) 


e 




Decoding of audio/video (slowest is used) 


f 



VT End - to - End Mean One - Way Transmission Time [s] = 
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6.7.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer; 

OR 

• intentional call release. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 


Attach Failure Ratio 




UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.12 VT Audio/Video Synchronization [%] 

6.7.12.1 Abstract Definition 

Percentage of times that the time differences of the audio and video signal at the user side exceeds a predefined 
threshold. 

Remarks: 

• This parameter is not calculated unless the VT audio/video setup attempt is successful. 

• Only if audio and video use different bearers this indicator would reflect the behaviour of the network and the 
mobiles. 

6.7.12.2 Abstract Equation 

To be specified. 



6.7.12.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successful 
audio/video setup 
attempt 


Start: Start of the audio and video 
output at both sides. 


Start: Start of reception of audio and video data at both 
sides from the opposite side. 

Comment: All four data streams shall be received for a 
success. 


End of call (intentional 
or dropped) 


Stop: End of call. 


Stop: 

End of continuous reception of audio and video data at 
both sides from the opposite side because of: 

• an interruption for a predefined duration or 
longer; 

OR 

• intentional call release. 
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Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


UMTS CS available 


Radio Network Unavailability 




UMTS CS attach successful 


Attach Failure Ratio 




UMTS CS service access successful 


VT Service Non-Accessibility 




UMTS CS audio/video Setup successful 


VT Audio/Video Setup Failure Ratio 





6.7.13 Signalling Diagrams 

These are the flow charts of a mobile originated call until the call release. The point of view is the MO side. 



UE 


J 






Node B 



. RACH: CCCH: RRC CONNECTION REQUEST <TM> 




2. RADIO LINK SETUP REOUEST 



3. RADIO LINK SETUP RESPONSE 



4. ESTABLISH REOUEST (AAL2) 



5. ESTABLISH CONFIRM (AAL2) 



6. DOWNLINK SYNCHRONISATION 



7. UPLINK SYNCHRONISATION 



Tstart JX) 



. FACH: CCCH: RRC CONNECTION SETUP <UM> 



9. INSYNCH IND 




RNC 







MSG / VLR 




11. DCCH: RRC CONNECTION SETUP COMPLETE <AM> 




MGW 
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UE 


J 





Node B 



1. RACH: CCCH: RRC CONNECTION REOUEST <TM> 




2. RADIO LINK SETUP REOUEST 



3. RADIO LINK SETUP RESPONSE 



L ESTABLISH REOUEST (AAL2) 



5. ESTABLISH CONFIRM (AAL2) 



6. DOWNLINK SYNCHRONISATION 



7. UPLINK SYNCHRONISATION 



I. FACH: CCCH: RRC CONNECTION SETUP <UM> 



9. INSYNCH IND 





10. RADIO LINK RESTORE INDICATION . 



11. DCCH: RRC CONNECTION SETUP COMPLETE <AM> 




RNC 







MSG / VLR 



MGW 



UE 



NodeB 



T 



12. DCCH: INITIAL DT [ CM SERVICE REQUEST ] <AM> 



17. DCCH: SECURITY MODE COMMAND <AM> 



18. DCCH: SECURITY MODE COMPLETE <AM> 



21 . DCCH: DLDT [ IDENTITY REQUEST ] <AM> (IMEI) 



22. DCCH: ULDT [ IDENTITY RESPONSE ] <AM> (IMEI) 



24. DCCH: ULDT [ SETUP ] <AM> 



28. DCCH: DLDT [ :ALL PROCEEDING ] <AM> 



RNC 



MSG / VLR 



13. SCCP CONNECTION RQ [ 

INITIAL UE MESSAGE 
[ CM SERVICE REQUEST ] ] 



14. SCCP CONNECTION 
CONFIRM 



15. COMMON ID 



16. SECURITY MODE COMMAND 



19. SECURITY MODE COMPLETE 




27. DT [ CALL PROCEEDING ] 





23. DT [ IDENTITY RESPONSE ] (IMEI) ^ 
f RANAP KT RANAP 1 



25. DT [ SETUP ] 
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UE 



UE 



NodeB 



33. RADIO LINK RECONFIG PREPARE 
' NBAP >^ C NBAP 

34. RADIO LINK RECONFIG READY 
35. ESTABLISH REOUEST (AAL2) 

36. ESTABLISH CONFIRM (AAL2) 
37. RADIO LINK RECONFIG COMMIT 




38. DCCH: RADIO BEARER SETUP <AM> 



40. DCCH: RADIO BEARER SETUP COMPLETE <AM> 



44. DCCH: DLDT [ ALERTING ] <AM> 



47. DCCH: DLDT [ CONNECT ] <AM> 



49. DCCH: ULDT [ CONNECT ACK ] <AM> 



NodeB 



51. DCCH: ULDT [ DISCONNECT ] <AM> 



55. DCCH: DLDT [ RELEASE ] <AM> 



56. DCCH: ULDT [ RELEASE COMPLET ] <AM> 



60. DCCH: RADIO BEARER RELEASE <UM> 



64. DCCH: RADIO BEARER RELEASE COMPLETE <UM> 



65. DCCH: RRC CONNECTION RELEASE <UM> 




Figure 28: Video telephony signalling flow chart 
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6.8 Web Browsing (HTTP) 

6.8.1 HTTP Service Non-Accessibility [%] 

6.8.1.1 Abstract Definition 

The service non-accessibility ratio denotes the probability that a subscriber cannot establish a PDP context and access 
the service successfully. 

6.8.1.2 Abstract Equation 



HTTP Service Non - Accessibility [%] = 

unsuccessful attempts to reach the point when content is received 
all attempts to reach the point when content is received 



xlOO 



6.8.1.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Service access attempt 


Start: User initiates the service 
access. 


Start: ATD command. 


Successful attempt 


Stop: First content is received. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Sending of the first GET 
command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.8.2 HTTP Setup Time [s] 
6.8.2.1 Abstract Definition 

The setup time describes the time period needed to access the service successfully, from starting the dial-up connection 
to the point of time when the content is sent or received. 



6.8.2.2 Abstract Equation 



HTTP Setup Time [s] = (t 



service access successful ~ ^service access start 



J[s] 
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6.8.2.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^service access start^ ^ime Of service 

access attempt 


Start: User initiates the service 
access. 


Start: AID command. 


^service access successful ■ Time Of 

successful service access 


Stop: First content is received. 


Stop Metliod A: Reception of tlie first data 
packet containing content. 

Stop Method B: Sending of the first GET 
command. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.8.3 HTTP IP-Service Access Failure Ratio [%] 
6.8.3.1 Abstract Definition 

The IP-service access ratio denotes the probability that a subscriber cannot establish a TCP/IP connection to the server 
of a service successfully. 



6.8.3.2 Abstract Equation 



HTTP IP - Service Access Failure Ratio [%] = 

unsuccessfiil attempts to establish an IP connection to the server 
all attempts to establish an IP connection to the server 



xlOO 



6.8.3.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


IP-Service access attempt 


Start: User enters the URL and hits 
"Return". 


Start: First [SYN] sent. 


Successful attempt 


Stop: Web page download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Sending of the first GET 
command. 


Unsuccessful attempt 


Stop trigger point not reached. 



Remark: 



• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.8.4 HTTP IP-Service Setup Time [s] 



6.8.4.1 Abstract Definition 

The IP-service setup time is the time period needed to establish a TCP/IP connection to the server of a service, from 
sending the initial query to a server to the point of time when the content is sent or received. 
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6.8.4.2 Abstract Equation 



HTTP IP - Service Setup Time [S] - (tjp-Semce access successful " tiP-Service access start )[^] 



6.8.4.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^IP-Service access start" "'"''^^ 
IP-Service access attempt 


Start: User enters the URL and hits 
"Return". 


Start: First [SYN] sent. 


^IP-Service access successful ■ "'"''^^ 

successful IP-Service access 


Stop: Web page download starts. 


Stop Method A: Reception of the first data 
packet containing content. 

Stop Method B: Sending of the first GET 
command. 



Remark: 



• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.8.5 HTTP Session Failure Ratio [%] 



6.8.5.1 Abstract Definition 

The completed session ratio is the proportion of uncompleted sessions and sessions that were started successfully. 



6.8.5.2 Abstract Equation 



. ^ ^ . uncompleted sessions 

HTTP Session Failure Ratio [%] = x 100 

successfully started sessions 



6.8.5.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Successfully started session 


Start: User enters the URL and hits 
"Return". 


Start: First [SYN] sent. 


Completed session 


Stop: The complete web page 
appears in the browser window. 


Stop: Reception of the last data packet 
containing content. 


Uncompleted session 


Stop trigger point not reached. 



Remark: 



• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.8.6 HTTP Session Time [s] 
6.8.6.1 Abstract Definition 

The session time is the time period needed to successfully complete a PS data session. 
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6.8.6.2 Abstract Equation 

HTTP Session Time [s] = (t^essionend " tsession start 



6.8.6.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^session start^ Time of Successfully 
started session 


Start: User enters the URL and hits 
"Return". 


Start: First [SYN] sent. 


tsessionend^Time when session 
completed 


Stop: The complete web page 
appears in the browser window. 


Stop: Reception of the last data packet 
containing content. 



Remark: 

• The PS bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.8.7 HTTP Mean Data Rate [kbit/s] 



6.8.7.1 Abstract Definition 

After a data link has been successfully established, this parameter describes the average data transfer rate measured 
throughout the entire connect time to the service. The data transfer shall be successfully terminated. The prerequisite for 
this parameter is network and service access. 

6.8.7.2 Abstract Equation 



^ „ user data transferred [kbit] 
HTTP Mean Data Rate [kbit/s] = — 

vdata transfer complete ~ ^data transfer start 

[s] 



6.8.7.3 Trigger Points 



The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (web page). 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Wa transfer start ■ 

successfully started data transfer 


Start: Web page download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Sending of the first GET 
command. 


Wta transfer complete^ Time when 

data transfer complete 


Stop: Web page download 
successfully completed. 


Stop: Reception of the last data packet 
containing content. 



Remark: 



• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 
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6.8.8 HTTP Data Transfer Cut-off Ratio [%] 
6.8.8.1 Abstract Definition 

The data transfer cut-off ratio is the proportion of incomplete data transfers and data transfers that were started 
successfully. 



6.8.8.2 Abstract Equation 



HTTP Data Transfer Cut - off Ratio [%] = 



incomplete data transfers 
successfully started data transfers 



■xlOO 



6.8.8.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Successfully started data transfer 


Start: Web page download starts. 


Start Method A: Reception of the first data 
packet containing content. 

Start Method B: Sending of the first GET 
command. 


Complete data transfer 


Stop: Web page download 
successfully completed. 


Stop: Reception of the last data packet 
containing content. 


Incomplete data transfer 


Stop trigger point not reached. 



Remark: 



• The mobile station is already attached (see clause 5.3), a PDP context is activated (see clause 5.5) and a 
service was accessed successfully (see Service Non-Accessibility). 



6.9 Web Radio 
6.9.1 General 

Web Radio is a term used for different types of audio streaming. Most popular, according to current perception, is the 
proprietary but de-facto- standard SHOUTCAST type which is used by WinAmp and AOL. There is an open source 
variant (ICECAST). The following descriptions refer to Shoutcast, if not mentioned otherwise. 

A typical Web radio basic scenario starts with starting up the respective client's Web Radio functionality. 

First step is retrieval of an Electronic Program Guide (EPG), typically in the form of a station list naming station name, 
genre of content offered by this station, and stream rate (which gives user's a hint on expected audio quality). This EPG 
is typically retrieved from a fixed-URL server, e.g. www. shoutcast.com . 

NOTE: Remark: For other clients and types of Web Radio, clients such as Windows Media Player or iTunes 
accessing respective portals are used. 

Next step is selection of a station from the list. This triggers an attempt to open the respective stream and start to receive 
content. Typically, before audio reproduction starts, the client will do some seconds of buffering. 
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6.9.2 Preconditions 

With reference to the technical description above, the following KPI belong to the basic scenario only which is 
characterized as follows: 

• EPG retrieval is not part of the scenario (because in typical listening situations this is done once for multiple- 
station access). It is assumed that the station ID is already known. 

• EPG retrieval can be seen, however, as a kind of scenario extension. 

6.9.3 Special remarks on Internet radio audio playback and buffering 

Characteristic for Internet Radio audio playback is the fact that with a typical client application, no quality impairment 
other than gaps in reproduction occur. In other words, there is no poor MOS value or other continuous quality indicator, 
but simply "silence" for a period of time which cannot be estimated by the user. This fact is important when it comes to 
the definition of a useful KPI for audio quality. 

Since the service is TCP-based and uses buffering, playback will continue until the buffer is empty. The buffer has a 
fixed maximum size, equalling a constant maximum playback time. If the buffer is full, the whole mechanism can be 
modelled by a simple differential model where new data flows in with a network-dependent data rate and flows out with 
a constant rate (playback stream rate). 

In the stationary case with buffer completely filled, incoming throughput is equal to playback stream rate, independent 
of the maximum throughput the network can deliver. If the buffer is less than full due to a previous drop in incoming 
data rate, incoming data rate will be higher (at the maximum throughput the network/IP level chain can deliver at this 
time) until the buffer is full again. 

6.9.4 Transaction Definition from User's perspective 

A Web Radio transaction consists of a single tune-in to a selected station, followed by music playback for a given time. 

• It is assumed that all servers being accessed (tune-in information server, stream server) are basically accessible 
and have sufficient downstream bandwidth. 

• It is assumed that the length of the tune-in list is not relevant for KPI precision under given conditions (time 
effects caused by different lengths of tune-in list to be negligible. 



6.9.5 Result Definition 

With respect to the technical description, a full Web Radio transaction has one of the following results. 



Result 


Definition 


Successful 


At least one packet of content was successfully received, and no time-out condition occurred 
up to the end of the scheduled playback time. 


Dropped 


The conditions for successful transaction was not met. Examples: Unsuccessful access to the 
tune-in or stream server, loss of internet connection during playback, or a gap in playback 
longer than a pre-defined time-out value. 



It shall be noted that according to this definition, a Web Radio transaction where effectively no useable audio playback 
was possible is still considered to be technically successful. It is assumed that the fact that the transaction was useless 
and probably most annoying to the user is reflected in another QoS describing subjective quality. Therefore, the 
situation is qualitatively equivalent to a technically stable speech telephony call with extremely poor audio MOS score. 

There is no "Failed" result because it is assumed that all phases of the transaction are part of service usage, and the 
impact of unsuccessful phases is equally negative in the user's perception. Failure therefore is always attributed to 
earlier phase such as establishment of basic internet access, or DNS access. This is, however, subject to discussion with 
respect to the A/B method distinction. 
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6.9.6 QoS Parameter Overview 

The following graph shows phases in web radio usage and the coverage by the defined QoS parameters. 



Phase (user perspective) 


Retrieve EPG 


Select station 


Listen to selected station 


Phase (KPI coverage) 


EPG Retrieval 


Tune-in 


Reproduction 
set-up 








Reproduction 



Please note that for the sake of "user perspective" Reproduction set-up and Reproduction are NOT seamlessly 
connected. Reproduction set-up QoS parameters are provided for diagnostic purposes. 

6.9.7 Web Radio EPG Retrieval Failure Ratio [%] 

6.9.7.1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot access the Web Radio EPG successfully. 

6.9.7.2 Abstract Equation 



Web Radio EPG Retrieval Failure Ratio [%] ■■ 



unsuccessful attempts to access the EPG 
all attempts to access the EPG 



xlOO 



6.9.7.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


EPG retrieval attempt 


Start: User accesses Web Radio 
EPG. 


Start: HTTP GET on EPG URL. 


Successful attempt 


Stop: EPG content successfully 
received. 


Stop: Successful reception of EPG content 
(HTTP 200 OK, eventually followed by 
additional blocks). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.8 Web Radio EPG Retrieval Time [s] 

6.9.8.1 Abstract Definition 

This parameter describes the time period needed to access the Web Radio EPG successfully. 

6.9.8.2 Abstract Equation 



Web Radio EPG Retrieval Time [s] = (tstop er " tstart.ER 



6.9.8.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^start ER- retrieval 
attempt 


Start: User accesses Web Radio 
EPG. 


Start: Time of sending the HTTP GET on EPG 
URL. 


^stop er" "'"'■^^ successful EPG 
retrieval attempt 


Stop: EPG content successfully 
received. 


Stop: Time of successful reception of EPG 
content (HTTP 200 OK, eventually followed by 
additional blocks). 
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6.9.9 Web Radio Tune-in Failure Ratio [%] 

6.9.9.1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot obtain the tune-in information for a Web Radio 
streaming server successfully. 

6.9.9.2 Abstract Equation 



. . ^ .1 . uHsucccssful tuHc " Ih attcmpts 

Web Radio Tune - in Failure Ratio [%] = ^ x 100 

all tune - in attempts 



6.9.9.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Tune-in attempt 


start: Attempt to retrieve tune-in 
information. 


Start: Obtain tune-in information via a HTTP 
GET to a location obtained from EPG. 


Successful attempt 


Stop: Receive tune-in information. 


Stop: Successful reception of tune-in 
information (HTTP 200 OK, eventually followed 
by additional blocks). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.10 Web Radio Tune-in Time [s] 

6.9.10.1 Abstract Definition 

This parameter describes the time period needed to obtain the tune-in information for a Web Radio streaming server 
successfully. 

6.9.10.2 Abstract Equation 



Web Radio Tune - in Time [s] - \ts,op_ji - ts,gj^_ji )[s] 



6.9.10.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^start Ti- of tune-in attempt 


Start: Attempt to retrieve tune-in 
information. 


Start: Time when HTTP GET is issued to a 
location obtained from EPG. 


^stop TI- °f successful tune- 
in attempt 


Stop: Receive tune-in information. 


Stop: Time of successful reception of tune-in 
information (HTTP 200 OK, eventually followed 
by additional blocks). 



6.9.1 1 Web Radio Reproduction Set-up Failure Ratio [%] 
6.9.1 1 .1 Abstract Definition 

This parameter denotes the probability that a subscriber cannot successfully start listening to a given Web Radio station. 
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6.9.1 1 .2 Abstract Equation 



Web Radio Reproduction Set - up Failure Ratio [%] 
unsuccessfiil reproduction set - up attempts 
all reproduction set - up attempts 



xlOO 



6.9.11.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Reproduction Set-up attempt 


Start: Attempt to retrieve audio 
stream. 


Start: Attempt to retrieve audio content from 
stream server listed in tune-in information 
(HTTP GET). 


Successful reproduction set-up 
attempt 


Stop: Indication that player starts 
buffering (may not be visible in all 
players). 


Stop: Reception of first block of content (audio 
data). 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9.12 Web Radio Reproduction Set-Up Time [s] 

6.9.12.1 Abstract Definition 

This parameter describes the time period from request of audio stream from Stream Server to reception of first data 
packet of audio content. 

Remark: 

• Actual start of reproduction from user's point of view will be this time plus the buffer-fill time which may be 
specific to a web radio client application. 

6.9.12.2 Abstract Equation 



Web Radio Reproduction Set - up Time [s] = (t 



Stop_RP " ^Start.RP 



>)[s] 



6.9.12.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^start RP- "'"''^^ Stream 
reproduction attempt 


Start: Indication tliat the audio 
stream is requested from server. 


Start: Time when HTTP GET is issued to 
Stream Server. 


^stop Rp Time of reception of first 
data packet of audio content 


Stop: Indication that buffering of 
content begins. 


Stop: Receive first encoded audio data (client 
application is buffering). 



Remark: 

• Indicators listed under "user's point of view", may not be shown by actual Web Radio client applications. 
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6.9.13 Web Radio Reproduction Cut-off Ratio [%] 

6.9.13.1 Abstract Definition 

This parameter denotes the probabiHty that a subscriber cannot successfully complete stream reproduction from a given 
Web Radio station for a given period of time. 

Remark: 

• Typically, web radio client applications use buffering; therefore actual audible reproduction will start a certain 
time after reception of first data packet. This parameter covers the whole reproduction time, starting from 
reception of the first data packet to avoid making assumptions for buffer length. 

6.9.13.2 Abstract Equation 



1 1- 1 • ^ r'r'T^ • unsuccessful listening attempts 

Web Radio Reproduction Cut - off Ratio [%] = ^xlOO 

all listening attempts 



6.9.13.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Listening attempt 


start: Attempt to retrieve audio 
stream. 


Start: Attempt to retrieve audio content from 
stream server listed in tune-in information 
(HTTP GET). 


Successful listening attempt 


stop: Reach the end of intended 
stream playback time without break 
in IP connection. 


Stop: Reach the end of intended stream 
playback time without break in IP connection. 


Unsuccessful attempt 


Stop trigger point not reached. 



6.9. 1 4 Web Radio Audio Quality 

Due to the nature of Web radio which is using TCP connections, expected degradation effects are audio "gaps" (silence) 
only, resulting in buffer-empty condition resulting from insufficient bandwidth. 

At this point in time, no commonly accepted definition of perceived audio quality under these conditions exists. 
Definition of such a MOS value would be outside of the scope of the STQ MOBILE group anyway. It is clear that for 
such a perceptual measure, all aspects of possible audio gaps need to be taken into account, namely: 

• gap duration; 

• frequency of gaps; 

• time between gaps. 

For the time being, it is recommended to report the basic data on gaps on an event basis only. 

In any case, codec and stream rate (encoded bit rate) needs to be part of measurement definition since it will have 
decisive impact on results. 
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6.10 WLAN service provisioning with HTTP based authentication 
6.10.1 Generic Signal Flow 



KPI legend: 

User API scan 
attempt ^ 

API list display 
M 

User WLAN 
connection attempt^ 

WLAN connection 
^ established 



UE 



I I I 



MLME-SCAN.request sent 
MLME-SCAN.confirm received 



WLAN Provider 
Access Point 











MLME-JOIN.request sent 
MLME-JO IN. confirm received 



"Connected to network" 
Target page request 



^ I^ndin^ pa^ejoade^ 

Send payment data and 
_ sessionsettin^ _ 



^ "Login Success" 

Target page request ^ 

(In case of no redirection) 

^ Target page loaded 
_ _ Ses^sioi^lo^out _ ^ 

^ "Logout success" 
User WLAN disconnection^ 



Authentication request 



Authentication confirm 



MLME-ASSOCIATE.request ^ 
^ MLME-ASSOCIATE.confirm 



DHCP.DISCOVER 



DHCP.ACK 



HTTP GET 



302 Moved temporarily 



HTTP GET Landing page 



Provider Landing Page 



I 



HTTP POST Pavment data 



Login success indication 



HTTP GET 



Target page 



I 



HTTP POST Logout 



Provider Logout page 



MLME-DISCONNECTED 



WLAN Provider 
Proxy 



Internet Service 
Provider 



Figure 29: Generic Signal Flow 
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6.1 0.2 WLAN Scan Failure Ratio [%] 

6.10.2.1 Abstract Definition 

The WLAN scan failure ratio denotes the probability that no desired active APs could be found in an area where 
WLAN should be present. 

6.1 0.2.2 Abstract Equation 



xxrx .^Tr. ^ . r^i unsuccessfol scan attempts 

WLAN Scan Failure Ratio [%] = x 100 

total attempts to scan WLAN APs 



WLAN UE 



WLAN Station WLAN Station 
Management Unit Scan Unit 




M LM E-SC AN . req uest ^ 




MLME-SCAN.confirm 


< 



Figure 30: SCAN Signal Flow 



6.10.2.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Scan attempt 


Start: User attempts to scan for 
available APs 


Start: First "MLME-SCAN. request" containing 
the target SSID sent 


Successful scan attempt 


Stop: List of available APs is 
displayed including desired SSID 


Stop: "MLME-SCAN.confirm containing the 
target SSID received 


Unsuccessful scan attempt 


Stop trigger not reached 



Preconditions for measurement: 

• It is possible that a scan to all access points in the area (Broadcast) is answered by an access point other than 
the desired one. To make sure that only the correct access point answers, the scan request shall contain the 
desired SSID. 

• Usually, operating systems keep a list of preferred access points and sporadically scan for these access points 
automatically. These automated scans shall be deactivated and the list shall be kept empty. 

For further study: It should be analysed if the time to scan can vary depending on the applied scan method, i.e. if an 
aimed scan with the target operator's SSID leads to faster/slower confirmation than a broadcast scan to all access points 
in the area. 

6.1 0.3 WLAN Time to Scan [s] 
6.10.3.1 Abstract Definition 

WLAN time to scan denotes the time it takes to scan for available access points. 
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6.10.3.2 Abstract Equation 

WLANTime to Scan [s]= (tsea„ result received " tscanstarted) t] 



WLAN UE 



WLAN Station WLAN Station 
lUlanagement Unit Scan Unit 




MLME-SCAN.request ^ 




4 lUILIUIBSCAN.confIrm 





Figure 31 : SCAN Signal Flow 



6.10.3.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


tscan Started: Time of scan attempt 


Start: User attempts to scan for 
available APs. 


Start: First "MLME-SCAN.request" containing 
the target SSID sent. 


^Scan result received: 

successful scan attempt 


Stop: List of available APs is 
displayed, including target SSID. 


Stop: "MLME-SCAN. confirm" containing the 
target SSID received. 



Preconditions for measurement: 

• It is possible that a scan to all access points in the area (Broadcast) is answered by another access point than 
the desired one. To make sure that only the correct access point answers, the scan request shall contain the 
desired SSID. 

• Usually, operating systems keep a list of preferred access points and sporadically scan for these access points 
automatically. These automated scans shall be deactivated and the list shall be kept empty. 

NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the time 
to scan. 

For further study: It should be analysed if the time to scan can vary depending on the applied scan method, i.e. if an 
aimed scan with the target operator's SSID leads to faster/slower confirmation than a broadcast scan to all access points 
in the area. 

6.10.4 WLAN PS Data Service Provisioning Failure Ratio [%] 

6.10.4.1 Abstract Definition 

The WLAN PS data service provisioning failure ratio denotes the probability that a user cannot get in position to access 
services in a WLAN area. 

6.1 0.4.2 Abstract Equation 



.^.^^^ . ^ . . . ^ ^ . r^i unsuccessfiil connect attempts 

WLAN PS Data Service Provisionmg Failure Ratio [%\ = — x 100 

all connect attempts 
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WLAN UE 



Figure 32: JOIN Signal Flow 
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Internal MLME-JOIN.conf received 
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Figure 33: WLAN PS Data Service Provisioning Signal Flow 
6.10.4.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Connect attempt 


Start: User attempts to connect to 
the wireless network. 


Start: First "MLME-JOIN. request" sent. 


Successful connect attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 


Unsuccessful connect attempt 


Stop trigger not reached. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The implicit authorization failure ratio also depends on the authorization method, e.g. voucher received 
by SMS versus credit card. Thus, measurements based on different authorization method cannot be 
compared. 

6.10.5 WLAN PS Data Service Provisioning Time [s] 

6.10.5.1 Abstract Definition 

The WLAN PS data service provisioning time denotes the time it takes until the user is authorized in WLAN and in 
position to access services. 
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6.1 0.5.2 Abstract Equation 



WLAN PS Data Service Provisioning Time [s] = (t 



Target URL received ^ Connect option selected 



)[s] 



WLAN UE 



WLAN Station 
\/lanagement Unit 



WLAN Statior 
Scan Unit 



MLME - JOIN.request 



l\/ILI\/IE- JOIN.confirm 



Figure 34: JOIN Signal Flow 

WLAN UE Access 

Point 



Internal MLME-JOIN.req sent 
Internal MLME-JOIN.conf received 



Authentication.req. 



Authentication.conf. 



Associate.req 



Associate.conf 



.Login success indication 



WLAN Provider 
Proxy 



Figure 35: WLAN PS Data Service Provisioning Signal Flow 
6.10.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^Connect option selected: "l"'"^® 

of connect attempt 


Start: User attempts to 
connect to wireless network. 


Start: First 'MLME-JOIN. request" sent. 


Wget URL received: 

successful connect attempt 


Stop: Authorization confirmed 
by receiving login success 
indication. 


Stop: Reception of the first data packet 
of a page indicating login success. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The implicit authorization time also depends on the authorization method, e.g. voucher received by SMS 
versus credit card. Thus, measurements based on different authorization method cannot be compared. 

NOTE 3: The implicit authorization time that is consumed for entering and receiving the password has an effect on 
the PS data service provisioning time. 
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6.10.6 WLAN Association Failure Ratio [%] 

6.10.6.1 Abstract Definition 

The WLAN association failure ratio denotes the probabihty that a user cannot establish a radio link with the chosen 
access point. 

6.1 0.6.2 Abstract Equation 

xxr^ .^r. . . ^ : X. . r^i unsuccessM association attempts 

WLANAssociation Failure Ratio [%\ = — x 100 

all association attempts 

WLAN UE Access Point 



Internal MLME-JOIN. request sent 
Internal MLME-JOIN.confirm received 




Authentication.req ^ 


Authentication.conf 


< 

Assoclate.req ^ 


Associate.conf 





Figure 36: WLAN ASSOCIATION Signal Flow 

6.10.6.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Association attempt 


Start: User attempts to connect to 
wireless network. 


Start: First "MLME-JOIN. request" sent. 


Successful association attempt 


Stop: Connection to access point 
established and displayed. 


Stop: "MLME-ASSOCIATE.confirm" received 
with status code "success". 


Unsuccessful association attempt 


Stop trigger not reached. 



6.1 0.7 WLAN Association Time [s] 
6.10.7.1 Abstract Definition 

The WLAN association time denotes the time it takes to associate with the chosen access point. 
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6.1 0.7.2 Abstract Equation 



WLAN Association Time [s] = (t 



Successful association ^ Association start 



.)[s] 



WLAN UE 



Access Point 



Internal MLME-JOIN. request sent 
Internal MLME-JOIN.confIrm received 



Authentication.req 





Authentication.conf 




< 


Associate.req 






Associate.conf 


► 



Figure 37: WLAN ASSOCIATION Signal Flow 



6.10.7.3 Trigger Points 



Event from abstract equation 


Trigger point from user's point 
of view 


Technical description/protocol part 


Wsociation start: 

association attempt 


Start: User attempts to connect to 
wireless network. 


Start: First "MLME-JOIN. request" sent. 


^Successful association: Time Of 

successful association attempt 


Stop: Connection to access point 
established and displayed. 


Stop: "MLME-ASSOCIATE.confirm" received 
with status code "success". 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
association time. 



6.1 0.8 WLAN IP Address Allocation Failure Ratio [%] 

6.10.8.1 Abstract Definition 

The WLAN IP address allocation failure ratio denotes the probability that a user is not allocated an IP address by the 
access point. 

6.10.8.2 Abstract Equation 



WLAN IP Address Allocation Failure Ratio % 



unsuccessful attempts to allocate IP address 
all IP address allocation requests 



xlOO 



6.10.8.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


IP address allocation request 


Start: Attempt to acquire network 
address and display of status. 


Start: First "DHCP.DISCOVER" sent. 


Successful attempt to allocate IP 
address 


Stop: Connection to network 
established and displayed. 


Stop: "DHCP.ACK" received with valid IP 
address. 


Unsuccessful attempt to allocate 
IP address 


Stop trigger not reached. 
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6.1 0.9 WLAN IP Address Allocation Time [s] 

6.10.9.1 Abstract Definition 

The WLAN IP address allocation time denotes the time it takes the access point to allocate an IP address to the user's 
system. 

6.10.9.2 Abstract Equation 



WLAN IP Address Allocation Time [s] = (1^. - tn.,u„,,,i„„ ) [s] 



6.10.9.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


t|P allocation start: Time Of IP 

address allocation request 


Start: Attempt to acquire network 
address and display of status. 


Start: First "DHCP.DISCOVER" sent. 


t|P reception: Time Of SUCCeSSful 

attempt to allocate IP address 


Stop: Connection to network 
established and displayed. 


Stop: "DCHP.ACK" received with valid IP 
address. 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the IP 
address allocation time. 

6.10.10 WLAN Landing Page Download Failure Ratio [%] 

6.10.10.1 Abstract Definition 

The WLAN landing page download failure ratio denotes the probability that the landing page to which a user will be 
redirected for login to the WLAN cannot be successfully downloaded after requesting the target page. 

6.10.10.2 Abstract Equation 



xxr^ A^T^ X. ^ . ^ . r^i unsuccessfial landing page download attempts 

WLAN Landing Page Download Failure Ratio [%] = — x 100 

all landing page download attempts 



6.10.10.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Landing page download attempt 


Start: User enters target URL and 
requests the desired page. 


Start: "HTTP_GET" for the target page sent. 


Successful landing page 
download attempt 


Stop: Landing page download 
finished. 


Stop: Last HTTP data packet of the landing 
page received. 


Unsuccessful landing page 
download attempt 


Stop trigger not reached. 



Preconditions for measurement: 

• The measurement system shall be disconnected from the WLAN prior to each measurement cycle. 

• The cache shall be emptied prior to each measurement cycle and keep alive shall be deactivated/suppressed. 
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6.1 0. 11 WLAN Landing Page Download Time [s] 

6.10.11.1 Abstract Definition 

The WLAN landing page download time denotes the time it takes for redirection and download of the landing page 
provided to login to the WLAN successfully, after the user has tried to access some webpage. 

6.1 0.1 1 .2 Abstract Equation 

WLAN Landing Page Download Time [s]= (ti^di„g p.^, successfully downloaded - twcbpagc resquest se„t ) t] 



6.10.11.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Wbpage request sent: 

landing page download attempt 


Start: User enters target URL and 
requests the desired page. 


Start: "HTTP_GET" for the target page sent. 


^Landing page successfully downloaded: 

Time of successful landing page 
download attempt 


Stop: Landing page download 
finished. 


Stop: Last HTTP data packet of the landing 
page received. 



Preconditions for measurement: 

• The measurement system shall be disconnected from the WLAN prior to each measurement cycle. 

• The cache shall be emptied prior to each measurement cycle and keep alive shall be deactivated/suppressed. 

NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page download time. 

6.10.12 WLAN Landing Page Password Retrieval Failure Ratio [%] 

6.10.12.1 Abstract Definition 

The WLAN landing page password retrieval failure ratio denotes the probability that the password to get submitted via 
the landing page is not received by the user. 

6.10.12.2 Abstract Equation 

..r^ .^.^ _ _ . _ . r^i unsuccessfiil password retrieval attempts 

WLAN Landing Page Password Retrieval Failure Ratio [%\ = — x 100 

all password retrieval attempts 



6.10.12.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Password retrieval attempt 


Start: Authorization form filled in 
and submitted. 


Start: "TCP SYN." 


Successful password retrieval 
attempt 


Stop: Depending on used service, 
e.g. SMS with password received 
successfully. 


Stop: Depending on used service, e.g. SMS 
with password received successfully. 


Unsuccessful password retrieval 
attempt 


Stop trigger not reached. 



NOTE: The password retrieval failure ratio can be neglected when the credit card payment method is used. 
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6.10.13 WLAN Landing Page Password Retrieval Time [s] 

6.10.13.1 Abstract Definition 

The WLAN landing page password retrieval time denotes the time it takes to request and receive a password to get 
submitted via the landing page. 

6.10.13.2 Abstract Equation 

WLAN Landing Page Password Retrieval Time [s]= (tp,,,^^,^ ^^^^^^^ - 1 Authorisation request submitted ) t] 



6.10.13.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Authorisation request submitted: "l"'"^® 

of password retrieval attempt 


Start: Authorization form filled in 
and submitted. 


Start: "TCP SYN". 


^Password received: Time of 

successful password retrieval 
attempt 


Stop: Depending on used service, 
e.g. SMS with password received 
successfully. 


Stop: Depending on used service, e.g. SMS 
with password received successfully. 



NOTE 1 : The password retrieval time can be neglected when the credit card payment method is used. 

NOTE 2: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page password retrieval time. 

6.10.14 WLAN Landing Page Authorization Failure Ratio [%] 

6.10.14.1 Abstract Definition 

The WLAN landing page authorization failure ratio denotes the probability that the user authorization process via the 
landing page is not successful. 

6.10.14.2 Abstract Equation 

.^.^ ^ . , . . ^ ^ . r^i unsuccessfial authorisation attempts 

WLAN Landmg Page Authorisation Failure Ratio [%\ = — x 100 

all authorisation attempts 



6.10.14.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Authorization attempt 


Start: Password or payment data is 
submitted. 


Start: "HTTP POST" sent. 


Successful authorization attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 


Unsuccessful authorization 
attempt 


Stop Trigger not reached. 



NOTE 1: After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators will display a login 
success page of sorts and not redirect the user to the initially entered URL. 

NOTE 2: The authorization failure ratio also depends on the authorization method, e.g. voucher received by SMS 
versus credit card. Thus, measurements based on different authorization method cannot be compared. 
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6.10.15 WLAN Landing Page Authorization Time [s] 

6.10.15.1 Abstract Definition 

The WLAN landing page authorization time denotes the time it takes to perform user authorization via the landing page. 

6.10.15.2 Abstract Equation 

WLAN Landing Page Authorisation Time [s] = (t^^^horisaUon confirmed " * Password is submiued M 



6.10.15.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^Password is submitted: Time Of 

authorization attempt 


Start: Password or payment data is 
submitted. 


Start: "HTTP POST" sent. 


Authorisation confirmed: "l"'"^® 

successful authorization attempt 


Stop: Authorization confirmed by 
receiving login success indication. 


Stop: Reception of the first data packet of a 
page indicating login success. 



NOTE 1 : After authorization, some operators will automatically redirect the user to the URL that was entered in the 
initial portal access attempt which led to the landing page redirection. Other operators display a login 
success page of sorts and do not redirect users to their initially entered URL. 

NOTE 2: The authorization time also depends on the authorization method, e.g. voucher received by SMS versus 
credit card. Thus, measurements based on different authorization method cannot be compared. 

NOTE 3: The authorization time that is consumed for entering and receiving the password has an effect on the 
landing page authorization time. 

6.10.16 WLAN Re-accessibility Failure Ratio [%] 
6.10.16.1 Abstract Definition 

The WLAN re-accessibility failure ratio denotes the probability that re-accessing the access point is not successful 
because of a WLAN failure. 



6.10.16.2 Abstract Equation 



WLAN Re - accessibility Failure Ratio [% J = 



unsuccess&l attempts reaccess 
all attempts to reaccess 



xlOO 



WLAN UE 



Access Point 





Associate.req 






Associate.conf 


> 





Figure 38: WLAN RE-ASSOCIATION Signal Flow 
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6.10.16.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Attempt to reaccess 


Start: Access point is displayed in 
the list of available access points. 


Start: First "MLME-ASSOCIATE.request" sent 
after radio signal is sufficient again. 


Successful attempt to reaccess 


Stop: Message that the WLAN 
adapter is ready (MAC address of 
AP is available). 


Stop: "MLME-ASSOCIATE.confirm" has been 
received with status code "success". 


Unsuccessful attempt to 
reaccess 


Stop trigger point not reached. 



6.1 0.1 7 WLAN Re-accessibility Time [s] 

6.10.17.1 Abstract Definition 

The WLAN re-accessibility time denotes the time it takes to re-establish a lost radio link with the access point after the 
signal is sufficient again. 

6.10.17.2 Abstract Equation 

WLAN Re - aCCeSSibiHty Time [s] ^ (t ^p., mac address is available - t AP reappears in list ) [s] 

WLAN UE Access Point 





Associate.req 






Associate.conf 


► 





Figure 39: WLAN RE-ASSOCIATION Signal Flow 



6.10.17.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


Up reappears in list: ^'me Of attempt 

to reaccess 


Start: access point is displayed in 
the list of available access points. 


Start: First "MLME-ASSOCIATE.request" sent 
after radio signal is sufficient again. 


Up"s IVIAC address is available: 

successful attempt to reaccess 


Stop: message that the WLAN 
adapter is ready. 


Stop: "MLME-ASSOCIATE.confirm" has been 
received with status code "success". 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
re-accessibility time. 

6.10.18 WLAN Logout Page Download Failure Ratio [%] 
6.10.18.1 Abstract Definition 

The WLAN logout page download failure ratio denotes the probability that the logout process is not successful. 
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6.10.18.2 Abstract Equation 

..r. ^ ^ , ^ . r^i unsuccessfiil logout page download attempts 

WLAN Logout Page Download Failure Ratio [% J = — — x 100 

all logout page download attempts 



6.10.18.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Logout page download attempt 


Start: Decision to logout is 
submitted. 


Start: "HTTP POST" sent. 


Successful logout page 
download attempt 


Stop: Logout confirmed by 
receiving logout page. 


Stop: Reception of first data packet of logout 
page. 


Unsuccessful logout page 
download attempt 


Stop Trigger not reached. 



6.10.19 WLAN Logout Page Download Time [s] 

6.10.19.1 Abstract Definition 

The WLAN logout page download time denotes the time it takes to perform user logout. 

6.10.19.2 Abstract Equation 

WLAN Logout Page Download Time [s] = (t^^^^^ ^^^^ - 1^^^^^^ p^cedure start ) t] 



6.10.19.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^Logout procedure start: Time Of 

logout page download attempt 


Start: Decision to logout is 
submitted. 


Start: "HTTP POST" sent. 


^Logout confirmed: ^^^^ 

successful logout page download 
attempt 


Stop: Logout confirmed by 
receiving logout page. 


Stop: Reception of first data packet of logout 
page. 



NOTE: The authorization time that is consumed for entering and receiving the password has an effect on the 
logout page download time. 

6.1 1 Wireless Application Protocol (WAP) 

WAP (Wireless Application Protocol) is a specification for a set of communication protocols to standardize the way that 
wireless devices, such as cellular telephones and radio transceivers, can be used for Internet access, including e-mail, 
the World Wide Web, newsgroups, and instant messaging. Devices and service systems that use WAP are able to 
interoperate. 

The WAP layers are: 

• Wireless Application Environment (WAE). 

• Wireless Session Layer (WSL). 

• Wireless Transport Layer Security (WTLS). 

• Wireless Transport Layer (WTP). 

WAP is a technology designed to allow efficient transmission of optimized Internet content to cell phones. 
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The QoS parameters for WAP are represented in Figure 40. 
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Figure 40: Parameter and service overview 

The Technical description/protocol part of the Parameters of the whole clause are represented in the following "WAP 
Message Sequence Chart" . 



UE 
1 

4 

5 

8 

9 

11 

14 

16 



- PDP Context Activation Request — - 
-- PDP Context Activation ACCEPT - 
WSP Connect or TCP SYN — - 



WSP Connect Reply or TCP SYN ACK o 

WTP ACK or TCP ACK »> 

WSP or HTTP Get Request »> 

-- First Data Packet containing content o 



Last Data Packet containing content - 



WWP 

2 
3 
6 
7 

10 
12 
13 

15 



Figure 41 : WAP Message Sequence Cliart 

NOTE: WSP Connection usually occurs once per session, TCP connection is more frequent. 

6.1 1 .1 WAP Activation Failure Ratio [%] (WAP 1 .x only) 
6.11.1.1 Abstract Definition 

The parameter WAP Activation Failure Ratio describes the probability that the WAP session could not be activated in 
case of WAP 1.x connection-mode session service. 
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6.11.1.2 Abstract Equation 

...AT^A . . ^ . unsuccessfiil WAP activation attempts 

WAP Activation Failure Ratio [%] = — x 100 

all WAP activation attempts 



6.11.1.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Technical description / 
protocol part 


WAP activation attempt 


Not applicable. 


Start: WSP Connect procedure. 


Successful WAP activation attempt 


Not applicable. 


Stop: Reception of the WSP Connect 
Reply. 


Unsuccessful WAP activation attempt 


Stop trigger point not reached. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). 

6.1 1 .2 WAP Activation Time [s] (WAP 1 .x only) 

6.1 1 .2.1 Abstract Definition 

The parameter WAP Activation Time describes the time it takes to activate the WAP session in case of WAP 1.x 
connection-mode session service. 

6.1 1 .2.2 Abstract Equation 

WAP Activation Time [S] = ( t wAP session established ' ^ WAP session activation request ) t^J 



6.11.2.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


WaP session activation request: 

session activation request. 


Not applicable. 


Start: WSP Connect procedure 


Wp session established: Time when WAP 

session established. 


Not applicable. 


Stop: Reception of the WSP Connect 
Reply 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3). Only successful measurements are taken into account to calculate the average time. 

6.1 1 .3 WAP {Page} IP Access Failure Ratio [%] (WAP 2.x only) 
6.1 1 .3.1 Abstract Definition 

The parameter WAP {Page} IP Access Failure Ratio denotes the probability that a subscriber cannot establish a TCP/IP 
connection to the WAP server successfully. 

NOTE: This parameter can only be calculated in case of follow up page, if the TCP/IP connection is not 
persistent. 
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6.1 1 .3.2 Abstract Equation 

...AT^rT^ . A ^ . unsucccssfiil WAP IP Acccss attcmpts 

WAP { Page } IP Access Failure Ratio [%] = — x 1 00 

all WAP IP Access attempts 



6.11.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description / 
protocol part 


WAP IP access attempt 


Start: Selecting the link of a WAP page or 
applying an entered URL 


Start: Sending of First TCP SYN 


Successful WAP IP 
access attempt 


Not applicable 


Stop: Sending of the first HTTP GET 
command 


Unsuccessful WAP IP 
access attempt 


Stop trigger point not reached 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 



6.1 1 .4 WAP {Page} IP Access Setup Time [s] (WAP 2.x only) 



6.1 1 .4.1 Abstract Definition 

The WAP {Page} IP Access Time is the time period needed to establish a TCP/IP connection to the WAP server, from 
sending the initial query to a server to the point of time when the content is demanded. 

NOTE: This parameter can only be calculated in case of follow up page, if the TCP/IP connection is not 
persistent. 



6.1 1 .4.2 Abstract Equation 

WAP {Page} IP Access Time [S] = (t wAPIP connection established " ^ WAP IP connection request ) t^] 



6.11.4.3 Trigger Points 



Event from abstract equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


^WAP IP connection request: Time Of 

WAP IP connection request. 


Start: Selecting the link of a WAP page 
or applying an entered URL. 


Start: Sending of First TCP SYN. 


^WAP IP connection established: ^^^^ 

WAP IP connection established. 


Not applicable. 


Stop: Sending of the first HTTP GET 
command. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 

6.1 1 .5 WAP {Page} Session Failure Ratio [%] 
6.1 1 .5.1 Abstract Definition 

The parameter WAP {Page} Session Failure Ratio is the proportion of unsuccessful WAP page access attempts and 
sessions that were started successfully. 
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6.1 1 .5.2 Abstract Equation 

...AT^rT^ . r. . ^ . unsucccssfiil WAP Dagc acccss attcmpts 

WAP { Page } Session Failure Ratio [%] = — — x 1 00 

all WAP page access attempts 



6.11.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


WAP page access 
attempt 


Start: 

Selecting the link of a WAP page or 
applying an entered URL. 


Start: 

WAP1 .x: Sending of WSP Get Request 
WAP2.X: 

a) Sending of First TCP SYN (if available); or 

b) Sending of HTTP Get Request (only if first TCP 
SYN is not available). 


Successful WAP page 
access attempt 


Stop: The requested WAP page is 
completely loaded. 


Stop: 

WAP1 .X/WAP2.X: Reception of the last data packet 
containing the corresponding content. 


Unsuccessful WAP 
page access attempt 


Stop trigger point not reached. 


NOTE: In case of WAP 2.x the start trigger should be the first TCP SYN (a). If the TCP/IP connection is not 
re-established before the request of the new page (next page part), the start Trigger has to be the first 
respective HTTP Get Request (b). 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6. 11 .6 WAP {Page} Session Time [s] 

6.1 1 .6.1 Abstract Definition 

The parameter WAP {Page} Session Time provides the time in seconds between selection of a specific WAP page and 
the successful load of the page. 

6.1 1 .6.2 Abstract Equation 



WAP { Page } Session Time [s] = ( t ^ ^^P page " t selection WAP page ) [s] 



6.11.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^selection WAP page: 

Time of selection of 
the WAP page 


Start: Selecting the link of a WAP 
page or applying an entered URL. 


Start: 

WAP1 .x: Sending of first WSP Get Request. 
WAP2.X: 

a) Sending of First TCP SYN (if available); or 

b) Sending of HTTP Get Request (only if first TCP 
SYN is not available). 


^appearance WAP page: 

Time of appearance 
of the WAP page 


Stop: The requested WAP page is 
completely loaded. 


Stop: 

WAP1 .X/WAP2.X: Reception of the last data packet 
containing the corresponding content. 


NOTE: In case of WAP 2.x the start trigger should be the first TCP SYN (a). If the TCP/IP connection is not 

re-established before the request of the new page (next page part), the start Trigger has to be the first 
respective HTTP Get Request (b). 
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Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 

6. 11 .7 WAP {Page} Request Failure Ratio [%] 

6.1 1 .7.1 Abstract Definition 

The WAP {Page} Request Failure Ratio denotes the probability that a WAP page request is not successful after a 
timeout period. 

6.1 1 .7.2 Abstract Equation 

„,.T^r^ , ^ ^ ■ unsuccessfiil WAP page request attempts 

WAP {Page} Request Failure Ratio [%] = ^ — ^ ^ — xlOO 

all WAP page request attempts 



6.11.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


WAP page request 
attempt 


Start: Selecting the link of the WAP 
page. 


Start: 

WAP1 .x: Sending of WSP Get Request 
WAP2.X: Sending of HTTP Get Request. 


Successful WAP page 
request attempt 


Stop: Download begins. 


Stop: 

WAP1 .X/WAP2.X: Reception of the first data packet 
containing content. 


Unsuccessful WAP 
page request attempt 


Stop trigger point not reached. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 1 .8 WAP {Page} Request Time [s] 

6.1 1 .8.1 Abstract Definition 

The parameter WAP {Page} Request Time describes the duration between selection of a specific WAP page and the 
reception of the first data packet containing WAP page content. 

6. 11.8.2 Abstract Equation 

WAP {Page} Request Time [s]= (t fct^ata packet reception - t selection WAPpage) [«] 



6.11.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^selection WAP page: 

selection of the WAP site. 


Start: Selecting the link of the 
WAP page. 


Start: 

WAP1 .x: Sending of WSP Get Request 
WAP2.X: Sending of HTTP Get Request. 


^first data packet reception: "^11^6 

of first data packet 
reception. 


Stop: Download begins. 


Stop: 

WAP1 .X/WAP2.X: Reception of the first data packet 
containing content. 
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Remark: 



• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 

6.11 .9 WAP {Page} Mean Data Rate [kbit/s] 

6.1 1 .9.1 Abstract Definition 

The WAP {Page} Mean Data Rate denotes the average data rate (WAP throughput) in kbit/s. 

6.1 1 .9.2 Abstract Equation 

^ ri 1 • / n WAP page size [kbyte] X 8 
WAP { Page } Mean Data Rate [kbit/s] = — — — 

last data packet reception ^ first data packet reception ) t^-l 



6.11.9.3 Trigger Points 



The average throughput is measured from opening the data connection to the end of the successful transfer of the 
content (file, WAP page). 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^first data packet reception: 

Time of first data 
packet reception 


Start: Download begins. 


Start: 

WAP1 .X/WAP2.X: Reception of the first data packet 
containing content. 


^last data packet reception: 

Time of last data 
packet reception 


Stop: Download is completed. 


Stop: 

WAP1 .X/WAP2.X: Reception of the last data packet 
containing the corresponding content. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.1 1 .1 WAP {Page} Data Transfer Cut-off Ratio [%] 

6.11.10.1 Abstract Definition 

The WAP {Page} Data Transfer Cut off Ratio denotes the probability that a data download is incomplete after a timeout 
period (the download is aborted). 

6.1 1 .1 0.2 Abstract Equation 

WAP{Page}DataTransferCutoff Ratio [%] ^l^^ggg^ e WAP page transfer atte mpt^ ^^^^ 

all WAP page transfer attempts 
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6.11.10.3 Trigger Points 



Event from 
abstract equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


WAP page transfer 
attempt 


Start: Download begins. 


Start: 

WAP1 .X/WAP2.X: Reception of the first data packet 
containing content. 


Successful WAP 
page transfer 
attempt 


Stop: Download is completed. 


Stop: 

WAP1 .X/WAP2.X: Reception of the last data packet 
containing the corresponding content. 


Incomplete WAP 
page transfer 
attempt 


Stop trigger point not reached. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). 

6.11 .11 WAP {Page} Data Transfer Time [s] 

6.11 .11 .1 Abstract Definition 

The parameter WAP {Page} Data Transfer Time describes the duration between the reception of the first data packet 
and the last data packet containing WAP page content. 

6.1 1 .1 1 .2 Abstract Equation 

WAP{Page} Data Transfer Time [s]= (t ^ data packet reception -t first data packet reception ) [S] 



6.11.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^first data packet reception: 

Time of first data 
pacl<et reception 


Start: Download begins. 


Start: 

WAP1 .X/WAP2.X: Reception of the first data packet 
containing content. 


^last data packet reception: 

Time of last data 
pacl<et reception 


Stop: Download is completed. 


Stop: 

WAP1 .X/WAP2.X: Reception of the last data packet 
containing the corresponding content. 



Remark: 

• The bearer has to be active in the cell used by a subscriber (see clause 5.1) and the mobile station has to be 
attached (see clause 5.3) as well as the respective PDP context has to be activated (see clause 5.5). Only 
successful measurements are taken into account to calculate the average time. 

6.12 IMS Multimedia Telephony 

The present clause describes QoS parameters for the IMS Multimedia Telephony service (MTSI) as described in 
TS 123 228 [25]. 

The IMS Multimedia Service consists of several services, such as video, voice and text. The MTSI parameters are 
related to the control plane, to real-time user services or non real-time user service as in Figure 40. 



ETSI 



158 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



MTSI Control Plane (SIP/SDR 

Registration 
Session setup 
Session add 
Session completion 



MTSI User Plane MTSI User Plane 

Realtime (RTP/UDP) Non-realtime (MSRP/TCP) 

Speecli quality Messaging 
Speech delay File or media sharing 

Video quality 
Video delay 
Real-time text 



Figure 42: MTSI parameter structure 



6.12.1 MTSI Registration Failure Ratio [%] 



6.12.1.1 Abstract Definition 

The MTSI registration failure ratio is the probabihty that the terminal cannot register towards IMS when requested. 
Remark: 



• A successful MTSI registration is required before the terminal can use any MTSI services, and before other 
terminals can setup MTSI sessions towards it. Even if it is technically possible to wait with the registering 
until the first use of any MTSI service, it is normally expected that registration is done at terminal power-on. 

6.12.1 .2 Abstract Equation 



nvyrrtnoxT^ • • M • n unsuccessful MTSI rcgistration atteHipts 

MTSI Registration Failure Ratio [%] = — x 100 

all MTSI registration attempts 
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UE P-CSCF 

(SMI) Register 



I-CSCF 



HSS 



S-CSCF 



(SM2) Register 



Cx- Selection -Info 



(SM3) Register 



Cx-Put 



(CMl) AV-Req 
(CM2) AV-Req-Resp 



(SM4) 4xx Auth_Challenge 



(SM5) 4xx Auth_Challenge 
(SM6) 4xx Auth_Challenge 4^ 



(SM7) Register 



^ (SMS) Register 



Cx-Query 



(SM9) Register 



(SMI 2) 2xx Auth_Ok 



(SMIO) 2xx Auth_Ok 
(SMll) 2xx Auth_Ok ^ 



<C ^ Cx-Pull ^ > 



Figure 43: Successful MTSI registration example 



Remark: 



• The first response to the REGISTER is normally a failure response, indicating that authentication must be 
done. The UE then makes a second REGISTER completed with the authentication information. After correct 
authentication the UE then receives the 200 OK message. 



6.12.1.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


MTSI registration attempt 


Start: Power-on or activation 
of any MTSI service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP 
REGISTER" message. 


Successful MTSI 
registration attempt 


Stop: MTSI availability is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" 
message. 


Unsuccessful MTSI 
registration attempt 


Stop: MTSI availability 
indication is not given within 
a pre-determined time. 


Stop: Protocol: SIP. 

Case 1 : Second data packet received by the terminal (after 
sending the "SIP REGISTER" message) containing a 
message different to "SIP 200 OK". 

Case 2: First data packet received by the terminal (after the 
authentication procedure) containing a message different to 
"SIP 200 OK". 

Case 3: No message received by the terminal within a 
pre-determined time. 



6.12.2 MTSI Registration Time [s] 
6.12.2.1 Abstract Definition 

The MTSI registration time is the time period between the IMS registration request and being registered to IMS. 
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6.12.2.2 Abstract Equation 

MTSI Registration Time [s] = (tMxsiAvaiiabie " tMxsiActivated 



6.12.2.3 Trigger Points 



Event from 
abstract equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


^MTSI Activated ^ Time 

of MTSI registration 
attempt 


Start: Power-on or activation 
of any MTSI service on the 
terminal. 


Start: Protocol: SIP. 

First data packet sent by the terminal containing a "SIP REGISTER" 
message. 


^MTSIAvailable ■ "'"''^^ 

of successful MTSI 
registration attempt 


Stop: MTSI availability is 
indicated. 


Stop: Protocol: SIP. 

First data packet received containing a "SIP 200 OK" message. 



6.12.3 MTSI Session Set-up Failure Ratio [%] 

6.12.3.1 Abstract Definition 

The MTSI Session Set-up Failure Ratio is the probabihty that the terminal cannot setup an MTSI session. An MTSI 
Session is initiated when the user presses the call button and receives a notification that the callee answers within a 
pre-determined time. 

Remarks: 

• In a normal SIP call, the user first receives a callee alerted notification; a series of "beep" tones that indicates 
that the terminating phone is ringing, until the callee answers the phone. However, for drive testing automatic 
answering will be used and in that case a session set-up notification is received directly instead of the callee 
alerted notification. The session set-up notification indicates that the other phone accepts the conmiunication. 

• An unsuccessful attempt may either be an attempt that is explicitly acknowledged by an error message from 
the terminating client/network or an attempt that does not results in any responses from the terminating 
terminal/network at all within a pre-determined time. 

6.12.3.2 Abstract Equation 

nvyrrr^oTo • o t • n unsucccssM MTSI scssion sctuD attcmpts 

MTSI Session Setup Failure Ratio [%] = *^xlOO 

all MTSI session setup attempts 
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6.12.3.3 Trigger Points 



Event from abstract 
equation 


Trigger points from user's 
point of view 


Technical description / protocol part 


MTSI session set-up 
attempt 


Start: User initiates session by 
pushing tine call button to make the 
call. 


Start: Protocol: SIP. 

The trigger from the IMS client that forces the 
SIP layer of the terminal to create a "SIP 
INVITE" and send it to the transport layers of 
the terminal. 


Successful MTSI 
session set-up attempt 


Stop: The user hears or sees an 
indication that the other phone 
accepts the invitation 


Stop: Protocol: SIP. 

The terminal has received a data packet 
containing the final "SIP 200 OK (INVITE)" 
message. 


Unsuccessful MTSI 
session set-up attempt 


Stop: The user receives a notification 
that the session set-up is cancelled, 
or do not receive any notification at all 
within a pre-determined time. 


Stop: Protocol: SIP. 

Example of unsuccessful case 1 : The terminal 
informs the IMS client that the SIP session 
set-up is cancelled after the terminal receives 
an error, cancel, or redirection message (e.g. a 
"403 Forbidden" or "488 Not Acceptable Here" 
message as response to the "SIP INVITE"). 
Example of unsuccessful case 2: The terminal 
does not receive any messages to react on 
within a pre-determined time. 



6.12.4 MTSI Session Set-up Time [s] 

6.12.4.1 Abstract Definition 

The MTSI Session Set-up Time is the time period between initiation of an MTSI session by e.g. pressing the call button 
and the reception of a notification that the session has been set-up. 

6.12.4.2 Abstract Equation 



MTSI Session Setup Time [S] - (t^ser receives notification " tuserinitiatessession) 
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IMS Client 



User initiates session 



Callee alerted 
notification 



Session set-up 
, notification 



Ternninal 



Initate session 
signal ^ 



IMS Core 



Establish 
Connection 



SIP INVITE 



Resource 
Reservation 



SIP 183 Session Progress 
SIP PRACK 



^ Alerted signal 



Session set-up 
signal 



_SJP_200_qK (P_RACK)_ 
SIP UPDATE 



^ SIP 200 OK (UPDATE) 



SIP 180 Ringing 



SIP 200 OK (INVITE) 



MTAS 



SIP INVITE 



SIP 183 Session Progress 
SIP PRACK 



_SjP 200 OK (_P_R_ACK)_ 

SIP UPDATE 
SIP 200 OK (UPDATE) 



SIP 180 Ringing 



SIP 200 OK (INVITE) 



SIP INVITE to 
terminating network 



SIP 183 Session 
Progress from 
terminating network 

SIP PRACK to 
terminating network 



^_ SIP 200 OK (PRACK) 

SIP UPDATE to 

terminating network 



SIP 200 OK (I IPOATE) 



SIP 180 Ringing from 
terminating network 



SIP 200 OK (INVITE) 



Figure 44: Implicit Initiation of the MTSI Session 

Remarks: 

• In a normal SIP call, the user first receives a callee alerted notification; a series of "beep" tones that indicates 
that the terminating phone is ringing, until the callee answers the phone. However, for drive testing automatic 
answering will be used and in that case a session set-up notification is received directly instead of the callee 
alerted notification. The session set-up notification indicates that the other phone accepts the communication. 

• In most normal use-cases the originating and terminating mobile terminals are in battery saving mode and do 
not have any radio bearers established prior the MTSI session set-up. In these cases, the mobile terminal must 
establish connection to RAN by establishing a radio bearer. The delay contribution to the total MTSI session 
set-up of this procedure cannot be regarded as insignificant. This is shown in Figure 42 by a dashed box 
labelled "Establish Connection". 

• All or a sub-set of the dashed arrows in Figure 42 occur in case that the mobile terminals involved in the call 
need to reserve media resources in the Radio Access Network (RAN) prior to starting the conmiunication. 
Hence, the session setup time depends on the resources needed for the media and if any resources was already 
reserved by the mobile terminals prior to the session set-up. 



6.12.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


^ user initiates session 


Start: User initiates session 
by pushing the call button. 


Start: Protocol: SIP. 

First data packet sent by the ternninal containing a "SIP 
INVITE" message. 


^user receives notification 


Stop: The user receives a 
notification that the other 
phone accepts the invitation. 


Stop: Protocol: SIP. 

First data packet received by ternninal containing SIP 200 
OK (INVITE). 
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6.12.5 MTSI Session Add Failure Ratio [%] 

6.12.5.1 Abstract Definition 

The MTSI Session Add Failure Ratio is the probability that the terminal cannot add a media component. The change is 
initiated when the user starts to modify an existing MTSI session by adding a media component. The user then receives 
a notification that the callee is alerted about the session change within a pre-determined time. Alternatively the 
terminating phone can have automatic consent to session changes configured. 

Remark: 

• The failure ratio can be dependent on the type of the added media component. 

6.12.5.2 Abstract Equation 



T.>rn.oTo . • unsucccssM MTSI scssioH add attcmpts 

MTSI Session Add Failure Ratio [%] = ^xlOO 

all MTSI session add attempts 



6.12.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


MTSI session add attempt 


Start: User modifies session by 
pushing appropriate button to add a 
media component to/in the session. 


Start: Protocol SIP. 

The trigger from the IMS client that forces 
the SIP layer of the terminal to create a 
"SIP INVITE" and send it to the transport 
layers of the terminal. 


Successful MTSI session 
add attempt 


Stop: Getting notification that the 
session change is accepted and e.g. 
the new media stream starts (when 
using automatic consent) or 
appropriate notification that the other 
terminal accept or reject the session 
change. 


Stop: Protocol SIP. 

The terminal has received a data packet 
containing the "SIP 180 Ringing" message 
or a "SIP 200 OK" message and informs 
the IMS client that perform a callee alerted 
notification or a session changed 
notification. 


Unsuccessful MTSI 
session add attempt 


Stop: The user receives a notification 
that the session change is cancelled, 
or do not receive any notification at all 
within a pre-determined time. 


Stop: Protocol SIP. 
Example of unsuccessful case 1 : The 
terminal informs the IMS client that the SIP 
session change is cancelled after the 
terminal receives an error, cancel, or 
redirection message (e.g. a "403 
Forbidden" or "488 Not Acceptable Here" 
message as response to the "SIP 
INVITE"). 

Example of unsuccessful case 2: The 
terminal does not receive any messages to 
react on within a pre-determined time. 



6.12.6 MTSI Session Add Time [s] 
6.12.6.1 Abstract Definition 

The MTSI Session Add Time is the time period from the start if changing a session (adding a media component) to the 
reception of a notification that the session has been changed. 

Remark: 

• The terminals involved must have an MTSI session ongoing before it can be modified. 
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6.12.6.2 Abstract Equation 



MTSI Session Add Time [s] = 



User Re ceivesChangeBotification ^UserModifiesSession 



IMS Client 



User modifies session 



Callee alerted 
notification 



Session changed 
^ notification 



Terminal 



Initate session 
signal ^ 



IMS Core 



SIP INVITE 



Resource 
Reservation 



SIP 183 Session Progress 
SIP PRACK 



Alerted signal 



Session set-up 
signal 



SIP 200 OK (PRACK) 
SIP UPDATE 



SIP 200 OK (UPDATE) 



SIP 180 Ringing 



SIP 200 OK (INVITE) 



MTAS 



SIP INVITE 



SIP 183 Session Progress 
SIP PRACK 



SIP 200 OK (_P_RACK)_ 

SIP UPDATE 
SIP 200 OK (UPDATE) 



SIP 180 Ringing 



SIP 200 OK (INVITE) 



SIP INVITE to 
terminating network 



SIP 183 Session 
Progress from 
terminating network 

SIP PRACK to 
terminating network 



SIP 200 OK (PRACK) 

SIP UPDATE to 

terminating network 



SIP 200 OK (UPDATE) 



SIP 180 Ringing from 
terminating network 



SIP 200 OK (INVITE) 



Figure 45: Modification of the IVITSI Session 

Remarks: 



• The MTSI session change signaUing to add a media component follows the same set of rules as the MTSI 
session set-up signalling. Therefore, the signalling diagrams in Figures 42 and 43 are almost identical. The 
main difference is that the terminals will already have one or more radio bearers established at session change 
and the radio connection does not need to be established as for the initial session set-up. 

• In the case of automatic consent to session changes, the terminating UE may not send any "SIP 180 Ringing" 
message. In that case the final session change notification (triggered by the "SIP 200 OK (INVITE)" message 
should be used as the final trigger point for session change latency measurements. 

• The dashed arrows and box in Figure 43 are optional signals and event that may occur in the case that one or 
two mobile terminals are involved in the session change. 

• All or a sub-set of the dashed arrows in Figure 43 occur in case that the terminals involved in the call needs to 
reserve resources in the radio access network (RAN) when adding a new media stream to the MTSI session. 
Hence, the setup time depends on the resources needed for the new media stream and the resources reserved 
by the mobile terminals prior to the session change. 



6.12.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description / protocol part 


t(user modifies session) 


Start: User modifies session by pushing 
appropriate button to add a media 
component to/in the session. 


Start: Protocol: SIP. 

First data packet sent by the terminal 

containing a "SIP INVITE" message. 


t(user receives cliange 
notification) 


Stop: Getting notification that the session 
change is accepted. 


Stop: Protocol: SIP. 

First data packet received by terminal 

containing SIP 200 OK (INVITE). 
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6.12.7 MTSI Session Remove Failure Ratio [%] 



6.12.7.1 Abstract Definition 

The MTSI Session Remove Failure Ratio is the probability that the terminal cannot remove a media component. The 
removal is initiated when the user starts to modify an existing MTSI session by removing a media component. The user 
then receives a notification that the callee is alerted about the session change within a pre-determined time. 
Alternatively the terminating phone can have automatic consent to session changes configured. 

6.12.7.2 Abstract Equation 



^.rr^r^^r^ ' ^ • n unsucccssfiil MTSI scssioii 161110 val attcmpts 

MTSI Session Remo ve Failure Ratio [%] = ^xlOO 

all MTSI session removal attempts 



6.12.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description / protocol part 


MTSI session removal 
attempt 


Start: User modifies session by 
pushing appropriate button to remove 
a media component to/in the session. 


Start: Protocol SIP. 

The trigger from the IMS client that forces 
the SIP layer of the terminal to create a 
"SIP INVITE" and send it to the transport 
layers of the terminal. 


Successful MTSI session 
remove attempt 


stop: Getting notification that the 
session change is performed. 


Stop: Protocol SIP. 

The terminal has received a data packet 
containing the "SIP 180 Ringing" message 
or a "SIP 200 OK" message and informs 
the IMS client that perform a session 
changed notification. 


Unsuccessful MTSI 
session removal attempt 


stop: The user receives a notification 
that the session change is cancelled, 
or do not receive any notification at all 
within a pre-determined time. 


Stop: Protocol SIP. 
Example of unsuccessful case 1 : The 
terminal informs the IMS client that the SIP 
session change is cancelled after the 
terminal receives an error message as a 
response to the "SIP INVITE"). 
Example of unsuccessful case 2: The 
terminal does not receive any messages to 
react on within a pre-determined time 



6.12.8 MTSI Session Remove Time [s] 



6.12.8.1 Abstract Definition 

The MTSI Session Remove Time is the time period from the start if changing a session (removing a media component) 
to the reception of a notification that the session has been changed. 

Remark: 

• The terminals involved must have an MTSI session ongoing before it can be modified. 



6.12.8.2 Abstract Equation 

MTSI Session Remove Time [S] = tuserRQceivesChangeBoUfication ~^UserModifiesSession 
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6.12.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(user modifies 
session) 


Start: User modifies session by pushing 
appropriate button to remove a media 
component from the session. 


Start: Protocol: SIP. 

First data packet sent by the terminal 

containing a "SIP INVITE" message. 


t(user receives 
ctiange notification) 


Stop: Getting notification that the session 
change is accepted. 


Stop: Protocol: SIP. 

First data packet received by terminal 

containing SIP 200 OK (INVITE). 



6.12.9 MTSI Session Completion Failure Ratio [%] 
6.12.9.1 Abstract Definition 

The MTSI Session Completion Failure Ratio is the probability that a successfully started MTSI call is ended by a cause 
other than intentional termination by A- or B -party. 



6.12.9.2 Abstract Equation 



MTSI Session Completion Failure Ratio [%] = 



unsuccessfoUy completed MTSI sessions 
all successfully started MTSI sessions 



xlOO 



IMS Client 



User releases session 



Release notification 



Ternninal 



Release 

session signal ^ 



IMS Core 



SIP BYE 



Release of 
Resources 



Session 
^ released signal 



SIP 200 OK (BYE) 



MTAS 



SIP BYE 



SIP 200 OK (BYE) 



SIP BYE to 
terminating network 



SIP 200 OK (BYE) 



Figure 46: Signalling to end an MTSI Session 



Remark: 



• The dashed box is an optional event that typically occurs in the case when a mobile terminal is used. The event 
is the release of resources that has been reserved in the Radio Access Network. 
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6.12.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Successfully started 
MTSI sessions 


Start: User initiates session by pushing 
the call button to make the call. 


Start: Protocol SIP. 

The terminal has sent INVITE and received a 
"SIP 200 OK (INVITE)" message. 


Successfully completed 
MTSI sessions 


Stop: The user is notified that the call has 
ended and that the phone is ready to 
initiate and receive other calls. 


Stop: Protocol SIP. 

The terminal has received a data packet 
containing the "SIP 200 OK" message as a 
response to a "SIP BYE" request and informs 
the IMS client that perform a release 
notification. 


Unsuccessfully 
completed MTSI 
sessions 


Stop: Beside the successful release 
cases described above, some session 
may be released unexpectedly. I.e. the 
call is dropped. 


Stop: Protocol SIP. 

Example of unsuccessful case: The terminal 
loses connectivity and no signalling and/or 
media can be sent or received. 



6.12.10 MTSI Speech Quality 

6.12.10.1 Abstract Definition 

The MTSI Speech Quality represents the end-to-end speech quahty of the service. 
Remarks: 

• The speech quahty can be measured for both the caller and the callee. 

• The acoustical behaviour of the terminal is not part of this speech quality measurement. 

• The speech quality can be measured with a full reference model taking the original speech sample and the 
degraded sample as input, or with a parametric model taking transport and terminal parameters as input. 

6.12.10.2 Abstract Equation 

The validation of the end-to-end quality is made using MOS-LQO scales. These scales describe the opinion of users 
with speech transmission and its troubles (noise, robot voice, echo, dropouts, time scaling introduced by the jitter buffer 
etc.) according to ITU-T Recommendation P.863 [31]. The scale used has to be reported. An aggregation for 
measurement campaigns or parts of it should be made on speech sample basis. 



6.12.10.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Not applicable. 


Start: Interchange speech samples 
between A-party and B-party. 


Start: Reception of first RTP packet containing a 
speech frame 


Not applicable. 


Stop: Session completion or 
session change, where the speech 
service is removed from the 
session. 


Stop case 1 : The terminal has received a data 
packet containing the "SIP 200 OK" message 
as a response to a "SIP BYE" request and 
informs the IMS client that perform a release 
notification. 

Stop case 2: The terminal has received a data 
packet containing the "SIP 200 OK" message 
and informs the IMS client that the speech 
service is no longer active. 
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6.12.1 1 MTSI Speech Transmission Delay [s] 

6.12.11.1 Abstract Definition 

The MTSI Speech Transmission Delay is the delay between sending speech packets from terminal A to receiving 
speech packets at terminal B, when the speech is conveyed in the context of an MTSI call. 

6.12.11.2 Abstract Equation 

MTSI Speech Transmission Delay [s] = t(B _ receives) - t(A_sends)[s] 



Microphone 


Encoder/ 
Packetizer 




Jitterbuffer/ 
Decoder 


Loudspeaker 


A_speaks ^ 






B hears 


Digitized 






RTP 




Synthesized 




speecli signal " 


► 

Transmission Delay 


speech signal ^ 


► 



Figure 47: The Speech Transmission Delay 



NOTE 1 : Since the delay can vary for each packet, it is not statistically sufficient to measure the delay only for the 
first packet. 

NOTE 2: The Speech Transmission Delay is not exactly the same as perceived by the end user. The Speech 
Transmission Delay does not include the delay introduce by the jitter buffer and the encoding and 
decoding delay. 



6.12.11.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(A_sends) 


Start: Ternninal A sends 
speech. 


Start: Protocol: RTP. 

Data packet sent by ternninal A containing speech data. 


t(B_receives) 


Stop: Speech received by 
ternninal B. 


Stop: Protocol: RTP. 

Corresponding data packet received by ternninal B 
containing speech data. 



6.12.12 MTSI Speech Path Delay [s] 

6.12.12.1 Abstract Definition 

The MTSI Speech Path Delay is the speech delay between reception of speech by the microphone in terminal A to the 
loudspeaker playing out the speech at terminal B, when the speech is conveyed in the context of an MTSI call. 

6.12.12.2 Abstract Equation 

MTSI Speech Path Delay [s] = t(B _ hears) - t(A _ speaks)[s] 
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Figure 48: The Speech Path Delay 

NOTE: Since the delay can vary during a call, it is not statistically sufficient to measure the delay only once. 



6.12.12.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(A_speaks) 


Start: A speaks into the 
microphone 


Start: Electrical signal at the nnicrophone. 

The speech is received at the microphone (acoustical 

delay not included) 


t(B_hears) 


Stop: The speaker at B plays 
the speech 


Stop: Electrical signal at the speaker 

The corresponding speech is played out by the speaker 

(acoustical delay not included) 



6.12.13 MTSI Video Quality 

6.12.13.1 Abstract Definition 

The MTSI Video Quality represents the end-to-end video quality of the service. 
Remarks: 

• The video quality can be measured for both the caller and the callee. 

• The visual behaviour of the terminal's display is not part of this video quality measurement. 

• The video quality can be measured with a full reference model taking the original video sample and the 
degraded sample as input, or with a parametric model taking transport and terminal parameters as input. 

6.12.13.2 Abstract Equation 

The validation of the end-to-end quality is made using the MOS scale. This scale describes the opinion of users using 
the video service with its degradations (blockiness, jerkiness, freezes, etc). An aggregation for measurement campaigns 
or parts of it should be made on video sample basis. 

Remark: 

• Objective video quality models are to be defined. 
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6.12.13.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Not applicable. 


Start: Interchange video between 
A-party and B-party. 


Start: Reception of first RIP packet containing a 
video frame. 


Not applicable. 


Stop: Session completion or 
session change, where the video 
service is removed from the 
session. 


Stop case 1 : The terminal has received a data 
packet containing the "SIP 200 OK" message 
as a response to a "SIP BYE" request and 
informs the IMS client that perform a release 
notification. 

Stop case 2: The terminal has received a data 
packet containing the "SIP 200 OK" message 
and informs the IMS client that the video service 
is no longer active. 



6.12.14 MTSI Video Transmission Delay [s] 

6.12.14.1 Abstract Definition 

The MTSI Video Transmission Delay is the delay between sending video packets from terminal A, and reception of 
video packets at terminal B, where the video is transmitted in the context of an MTSI video call. 

6.12.14.2 Abstract Equation 

MTSI Video Transmission Delay [s] - t(B _ receives) - t(A_sends)[s] 
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Figure 49: The Video Transmission Delay 

NOTE 1 : Since the delay can vary for each packet, it is not statistically enough to measure only the delay for the 
first packet. 

NOTE 2: The Video Transmission Delay is not exactly the same as perceived by the end user. The Video 
Transmission Delay does not include the delay introduce by the jitter buffer and the encoding and 
decoding delay. 



6.12.14.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description / protocol part 


t(A_sends) 


Start: Ternninal A sends video. 


Start: Protocol: RTP. 

Data packet sent by ternninal A containing video 
data. 


t(B_receives) 


Stop: Video received at 
ternninal B. 


Stop: Protocol: RTP. 

Corresponding data packet received by ternninal B 
containing video data. 
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6.12.15 MTSI Video Path Delay [s] 

6.12.15.1 Abstract Definition 

The MTSI Video Path Delay is the delay between capturing of video at terminal A and display of the video at 
terminal B, where the video is transmitted in the context of an MTSI video call. 

6.12.15.2 Abstract Equation 

MTSI Video Path Delay [s] = t(B _displays) - t(A_captures)[s] 
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Figure 50: The Transmission Delay 

NOTE: Since the delay can vary during the session, it is not statistically sufficient to measure the delay only once. 



6.12.15.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(A_captures) 


Start: Ternninal A captures 
the video 


Start: Ternninal A captures a video frame 


t(B_displays) 


Stop: Terminal B displays 
the video 


Stop: Terminal B displays the corresponding video 
frame 



6.12.16 MTSI Audio/Video De-Synchronization [%] 
6.12.16.1 Abstract Definition 

The MTSI Audi/Video De-Synchronization is the percentage of time that the time differences of the audio and video 
signal (the "lip sync") at the receiving side is outside two thresholds, in the context of an MTSI combined audio/video 
call. 

The de-synchronization impacts the perceived quality of the service. For broadcasting purposes ITU-R 
Reconmiendation BT. 1359-1 [26] defines detectability and acceptability thresholds for lip synchronisation. Figure 49 
describes these thresholds. Note that the curve is not symmetrical around zero, as it is more annoying if the speech is 
played out too early than too late. 
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Figure 51 : The impact of audio video de-synchronization on perceived quality 

6.12.16.2 Abstract Equation 

NOTE: The equation below only calculates the lip sync at a certain position in the video transmission. The 
measurement frequency it is still to be defined to get useful measurement results. 

MTSI Audio Video De - Synchronization = Video Path Delay versus Speech Path Delay [s] = 
t{B _ view) - t{B _ hear) 



6.12.16.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(B_hear) 


The loudspeaker at B plays 
the speech 


Electrical signal at the speaker playing a speech frame 
The speech is played out by the speaker (acoustical 
delay not included) 


t(B_view) 


The display at B displays 
the video corresponding to 
the speech 


The rendering of a the video frame corresponding to the 
speech frame 



6.12.17 MTSI Real-Time Text Failure Ratio [%] 



6.12.17.1 Abstract Definition 

The MTSI Real-Time Text Failure Ratio is the proportion of not displayed letters and total number of letters sent in a 
successfully started MTSI real-time text session. 

Remark: 



• Real-time text is a real-time conmiunication method and it is important that the end-to-end delay is low. 
Therefore, when measuring the success ratio, letters that are received with a delay longer than a pre- 
determined time should be regarded as lost. 

6.12.17.2 Abstract Equation 



n.>rrT.ox 1 rr.. rr. ^ ^ ' Numbcr of Hot (11 splayeclletters Ih realtime tcxt scsslon 

MTSI Real - Time Text Failure Ratio = ^-^ x 100 

Number of typed letters in realtime text session 
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6.12.17.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Started MTSI real-time 
text session 


Start: User A initiates/modifies an MTSI 
session with user B so it includes 
real-time text. This is indicated to the 
users, and they start to communicate 
using text. 


Start: The first typed real-time text is captured 
and is sent to the transport layers of the 
terminal. The real-time text protocol stack 
may use redundancy (i.e. the letters are sent 
multiple times) to make the communication 
more robust to loss of data packets. 


Completed MTSI real- 
time text session 


Stop: One of the users pushes the 
end/modify call button to end the MTSI 
real-time text communication. The 
session ends or is modified and this is 
indicated to the users. 


Stop: The last part of the real-time text 
conversation is captured and sent by the 
terminal. Followed by the release or 
modification (drop of the real-time text media) 
of the SIP session. 


Number of not displayed 
letters 


During the real-time text communication, 
some letters may be lost or delayed 
which leads to impairments of the text 
communication. 


Example of unsuccessful case 1 : data 
packets containing text are lost or received 
too late and even if redundancy was applied 
parts of the typed text string are lost and 
cannot be displayed correctly or displayed in 
time. 

Example of unsuccessful case 2: The 
transport of real-time text data stops 
unexpectedly. 



6.12.18 MTSI Real-Time Text Delivery Time [s] 
6.12.18.1 Abstract Definition 

The MTSI Real-Time Text Delivery Time is the delay between sending a character from terminal A and reception of 
the same character in terminal B. 

Remarks: 

• The recommendation in the standard is to buffer text input 300 ms before sending the typed characters, and the 
maximum allowed buffering time is 500 ms. This means that normally only one or a few characters are 
typically transmitted to the other end in each RTP packet. 

• The default redundancy scheme is to send the last two text packets together with the most recent text packet. In 
this way up to two consecutive RTP packets can be lost without losing any characters. However, other 
redundancy schemes can be used, and it is up to the terminal vendor to select an appropriate scheme depending 
on the current channel conditions. 



6.12.18.2 Abstract Equation 

NOTE: Since the delay can vary for each packet, it is not statistically enough to measure only the delay for the 
first packet. 



MTSI RealTime Text Delivery Time = tg ^^^^-^^ - 



6.12.18.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


T(A_send) 


Start: User A writes a character. 


Start: Protocol: RTP. 

Data packet sent by terminal A containing the 
typed character. 


t(B_receive) 


Stop: User B receives tine cliaracter on 
iiis screen. 


Stop: Protocol: RTP. 

Corresponding data packet received by 

terminal B containing the same character. 
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6.12.19 MTSI Messaging Failure Ratio [%] 
6.12.19.1 Abstract Definition 

The MTSI Messaging Failure Ratio is the proportion of not received messages and sent messages in an MTSI 
messaging session. 



6.12.19.2 Abstract Equation 



MTSI Messaging Failure Ratio = 



Number of not received messages 
Total number of sent messages 
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Figure 52: Messaging using IVISRP 



Remark: 



Before a message can be sent, an MTSI Session must either be established or modified so it contains 
messaging. Further a TCP connection for MSRP transfer must be established between the two terminals. 
Typically, the MTSI Session and the TCP connection is established or modified when an end user opens up the 
messaging application on his phone e.g. during a call. The message is sent using MSRP in a later stage, that 
happens when the user has typed the message using the messaging application and he/she has pressed the 
"send button". 
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6.12.19.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Start of MTSI Messaging 
session 


Start: User A initiates/modifies an MTSI 
session with user B so it includes 
messaging. This is indicated to the users, 
and they send messages. 


Start: The trigger from the IMS client that starts 
the messaging session set-up that is followed 
by a number of message transmissions. 


Completed MTSI 
Messaging session 


Stop: One of the users pushes the 
end/modify call button to end the MTSI 
messaging exchange. The session ends 
or is modified and this is indicated to the 
users 


Stop: The messaging communication ends. 
Followed by the release or modification (drop of 
the messaging service) of the SIP session. 


Received messages 


Messages are delivered to user B. 


Successful case: The terminal receives the 
"MSRP 200 OK", in time, which acknowledges 
the reception of the message. This is indicated 
to the IMS client who notifies the user. 


Not received messages 


Messages either are not delivered to user 
B, or they are not delivered within a pre- 
determined time 


Example of unsuccessful case 1 : The terminal 
receives an error message (i.e. a "MSRP 4xx or 
MSRP 5xx message), which is indicated to the 
IMS client. 

Example of unsuccessful case 2: The 
connectivity is lost by one or both of the 
terminals and no MSRP messages is 
sent/received by the terminal within a 
pre-determined time 



6.12.20 MTSI Messaging Delivery Time [s] 

6. 1 2.20. 1 Abstract Definition 

The MTSI Messaging Delivery Time is the delay between sending a message from terminal A and reception of the 
same message in terminal B, where the terminals are involved in an MTSI messaging communication. 

6.12.20.2 Abstract Equation 



MTSI Messaging Delivery Time = t^essage.received - t Message. 



6.12.20.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


t(Message_sent) 


Start: User A sends a message. 


Start: Protocol: MSRP 

The message is sent using MSRP SEND. 


t(Message_received) 


Stop: User B receives the message. 


Stop: Protocol: MSRP 

The corresponding MSRP SEND message is 
received at terminal B. 



NOTE: An alternative method would is to measure the time between MSRP SEND and MSRP 200 OK, which 
then can be measured in the same terminal. However, the reception of MSRP 200 OK is not necessarily 
shown to the end user (depending on terminal implementation). 
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6.12.21 MTSI File/Media Sharing Failure Ratio [%] 
6.12.21.1 Abstract Definition 

The MTSI File/Media Sharing Failure Ratio is the proportion of uncompleted file/media sharing sessions and sessions 
that were started successfully. 

Remark: 

• The files can either be a generic file, or a file with a predetermined file and media format. 



6.12.21.2 Abstract Equation 



MTSI File/Media Sharing Failure Ratio = 



uncompleted file/media sharing sessions 
successfully started file/media sharing sessions 



-xlOO 



6.12.21.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Successfully started 
file/media sharing session 


Start: User A initiates/modifies an 
MTSI session with user B so it 
includes file/media sharing. This is 
indicated to the users, and they 
send files. 


Start: The trigger from the IMS client that starts 
the file/media sharing session set-up that is 
followed by the file transmission. 


Completed file/media 
sharing sessions 


Stop: One of the users pushes the 
end/modify call button to end the 
MTSI file/media sharing. The 
session ends or is modified and 
this is indicated to the users 


Stop: The file/media sharing ends. Followed by 
the release or modification (removal of the 
file/media sharing) of the SIP session. 


Total number of sent files 


Start: User A initiates/modifies an 
MTSI session with user B so it 
includes file/media sharing. This is 
indicated to the users, and they 
send files. 

Stop: One of the users pushes the 
end/modify call button to end the 
MTSI file/media sharing. The 
session ends or is modified and 
this is indicated to the users 


Start: The trigger from the IMS client that starts 
the file/media sharing session set-up that is 
followed by the file transmission. 
Stop: The file/media sharing ends. Followed by 
the release or modification (removal of the 
file/media sharing) of the SIP session. 


Uncompleted file/media 
sharing sessions 


Files either are not delivered to 
user B, or they are not delivered 
within a pre-determined time. 


Successful case: The terminal receives the 
"MSRP 200 OK" that acknowledges the 
reception of the file. This is indicated to the IMS 
client who notifies the user. 
Example of unsuccessful case 1 : The terminal 
receives an error message (i.e. a "MSRP 4xx or 
MSRP 5xx message) 
Example of unsuccessful case 2: The 
connectivity is lost by one or both of the 
terminals and no MSRP messages is 
sent/received by the terminal within a 
pre-determined time 



6.12.22 MTSI File/Media Sharing Mean Data Rate [kbit/s] 



6.12.22.1 Abstract Definition 



The Multimedia Telephony File/Media Sharing Mean Data Rate is the average data transfer rate measured of a 
successful transfer of a file or pre-determined media type. 
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6.12.22.2 Abstract Equation 



^^rr^c^T^ ^ /iv>r 1- oi • Tv>r rii n Amouiit of uscf data transfciTed [kbl 

MTSI File/Media Sharing Mean Data Rate [kbps] = ^ ^ 



t(ContentSent) - t(ConnectionEstablished) 
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Figure 53: File/Media Sharing using MTSI 



Remarks: 



• MTSI File/Media Sharing uses the same user plane protocol suite as MTSI Messaging. Thus the two methods 
of communication follow the same set of rules but with one exception. The exception is that for file/media 
sharing only one MSRP transaction is allowed per established or modified SIP session. Hence, after the file is 
successfully transferred the MTSI Session is either terminated or modified to not contain file/media sharing. 



• The time it takes from the user initiates the file/media transfer until he receives the file/media delivered 
notification can be divided into two parts. The first part is the access time, which is marked in the Figure as the 
time between "User initiate file/media transfer" until "File/media start transfer notification". The second part is 
the transfer time that is the time between the "File/media start transfer notification" and the "File/media 
delivered notification". This KPI aims to measure the average data rate during the transfer time. 

• In file/media sharing the content is usually several MTUs large, therefore the MSRP SEND message that 
contains the payload is segmented into a number of data packets. 



6.12.22.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


Amount of user data 
transferred (in kbit) 


The users use the file/media sharing 
enabler to send a file with known 
size. 


User A sends a file with known size to User 
B. 


t(connection establistied) 


Start: When the actual transmission 
of the file/media starts. At this 
moment the user is given a file/media 
start of transfer notification. 


Start: Protocol: MSRP 

The MSRP SEND message containing the 

file data is transmitted. 


t(content sent) 


Stop: The successful reception of the 
file, which result in a file/media 
delivered notification. 


Stop: Protocol: MSRP 

The terminal receives the "MSRP 200 OK" 

that acknowledges the reception of the file. 
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6.12.23 MTSI Media Setup Time [s] 
6.12.23.1 Abstract Definition 

The MTSI Media Set-up Time is the (non-negative) time period between the successful setup of the signalHng part of 
the MTSI call setup, and the receipt of the first packet containing valid (i.e. expected) media payload. 



6.12.23.2 Abstract Equation 



MTSI Media Setup Time - Max[(tf^g^^^i-^ ^^^^-^ packet received ~ ^ successful signalling setup )' ^] 
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Figure 53a: Media setup delayed due to NAT devices 



Remarks: 



In most cases the media path will be opened at the same time as the signalling path; for instance when there 
are no NAT (Network Address Translator) devices in the call path, or when the NAT devices are managed 
by the operator (for instance the SBC, Session Border Controller) and opened up automatically during the 
signalling phase. In such cases the media delay might be zero, or even negative (any negative values should 
however be set to zero for this parameter). 

If non-managed NAT devices are present in the call path, it is the responsibility of the terminals to open 
these by sending media or by using protocols such as ICE [29] or STUN [30]. In such cases the media 
setup time might be substantially larger than zero, depending on the methods used to open the NAT 
pinholes. 
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6.12.23.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


tsuccessful signalling setup 


Start: The user receives a 
notification that the other 
phone accepts the invitation. 


Start: Protocol: SIP. 

First SIP 200 OK received after initiating a session. 


tfirst valid media packet received 


Stop: The media is played 
out to the user. 


Stop: Protocol: SIP. 

First valid media packet received. 



6.12.24 MTSI Media Add Time [s] 

6.12.24.1 Abstract Definition 

The MTSI Media Add Time is the (non-negative) time period between the successful change of a session (adding a 
media component), and the receipt of the first packet containg vahd (i.e. expected) payload for the new media 
component. 

Remark: 

• The terminals involved must have an MTSI session ongoing before it can be modified. 

6.12.24.2 Abstract Equation 



MTSI Media Add Time — Max[(tgj.g^^^ii^jj^g^j^p^^j^g^j.g^g.^g^ tg^^^^ggf^jig-gj^^jj-j^g ^^^^p ), o] 



Remark: 

• The MTSI Media Add Time is similar to the MTSI Media Setup Time, except that the terminals will 
already have at least one media session open. Depending on the NAT structure in the call path, the time 
until the first media packet might be zero or even negative (when NATs are already open due to the 
existing media session) or significant (when NAT pinholes needs to be opened by the terminals). Any 
negative values should be set to zero for this parameter. 



6.12.24.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description / protocol part 


tsuccessful signalling setup 


Start: The user receives a notification 
that the other phone accepts the added 
media invitation. 


Start: Protocol: SIP. 

First SIP 200 OK received after initiating 
the session change. 


tfirst valid media packet received 


Stop: The added media is played out to 
the user. 


Stop: Protocol: SIP. 

First valid media packet for the added 

media is received. 



6.13 E-mail 

Please refer to clause 7.2, as the parameters described there are usable for direct service as well if notification is 
disabled on the e-mail server. 

All QoS parameters from clause 7.2 can be used with the exception of those dealing with notification (see 
clauses 7.2.10 and 7.2.11). 



ETSI 



1 80 ETSI TS 1 02 250-2 V2.2.1 (201 1 -04) 

6.14 Group Call 

6.14.1 Group Call Service Non-Accessibility [%] 

6.14.1.1 Abstract Definition 

The group call service non-accessibility denotes the probability that the end-user cannot access the group call service 
when requested by pushing the Push To Talk (PTT) button. 

6.14.1.2 Abstract Equation 



^ ^ ,,r. . . r^-, unsuccessful group call attempts 

Group Call Service Non - Accessibility [%] = — — x 100 

all group call attempts 



6.14.1.3 Trigger Points 

TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


Group call attempt 


Start: Push PTT button. 


Start: 

Layer 3 (CMCE): The "U-SETUP" message is sent from 
the A-party. 

AT: The "ATD <dial string>" command is sent from the 
A-party, where <dial string> provides a unique 
identification of the desired group. A preceding 
"AT+CTSDC" command is used to set the correct 
parameters for the dial command. 


Successful group call 
attempt 


Stop: The acoustic and/or 
optical indication is given to 
the A-party user that the 
group call is established. 


Stop: 

Layer 3 (CMCE): The "D-CONNECT" message is sent 
from the SwMI to the A-party. 

AT: The "AT+CTCC" indication is received by the A-party. 


Unsuccessful call attempt 


Stop trigger point not reached. 


NOTE: For the group call service non-accessibility it is not necessary to check the possibly involved B-parties (other 
group members) for a setup indication, e.g. a "D-SETUP" message, because the group call is actually 
established towards the network, i.e. the SwMI - no matter if there is any B-party connected to the group call 
or not. 



Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






No active group call 
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Figure 54: Group call setup procedure 

6.14.2 Group Call Setup Time [s] 
6.14.2.1 Abstract Definition 

The group call setup time is the time period between pushing the Push To Talk (PTT) button at the UE and receipt of 
call set-up notification by an acoustical and/or optical indication at the UE that the group call is successfully 
established. 



6.14.2.2 Abstract Equation 



Group Call Setup Time [s] = (/ 



connection established ^user pressed button 



6.14.2.3 Trigger Points 

TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


^user pressed button- "'"''^^ 

attempt 


Start: Push PTT button. 


Start: 

Layer 3 (CMCE): The "U-SETUP" message is sent from 
the A-party. 

AT: The "ATD <dial string>" command is sent from the 
A-party, where <dial string> provides a unique 
identification of the desired group. A preceding 
"AT+CTSDC" command is used to set the correct 
parameters for the dial command. 


^connection establislied' "T'l^e 
when connection is 
established (successful call 
attempt) 


Stop: The acoustic and/or 
optical indication is given to 
the A-party user that the 
group call is established. 


Stop: 

Layer 3 (CMCE): The "D-CONNECT" message is sent 
from the SwMI to the A-party. 

AT: The "AT+CTCC" indication is received by the A-party. 
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Preconditions for measurement: 



Precondition 


Covered by 


Reference document 


CS network available 


Radio Network Unavailability 




CS attach successful 






CS service access successful 


Group Call Service Non-Accessibility 





6.14.3 Group Call Speech Quality on Call Basis 

6.14.3.1 Abstract Definition 

The group call speech quality on call basis is an indicator representing the quantification of the end-to-end speech 
transmission quality of the group call service. This parameter computes the speech quality on the basis of completed 
calls. 

NOTE 1 : The acoustic behaviour of terminals is not part of this speech quality measurement. 

NOTE 2: The speech quality in group calls is measured at any receiving B -party, i.e. at every group member in 

receiving state. Thus, the overall speech quality for one group call may vary among the receiving B -party 
UEs. It is up to the following analysis to aggregate and evaluate the different results. 

6.14.3.2 Abstract Equation 

The applicability of a suitable speech quality evaluation method for the narrow-band speech codec within TETRA 
networks is for further study. 

6.14.3.3 Trigger Points 

The group call speech quality on call basis is derived from speech transmission during the duration of the entire group 
call. Trigger points are therefore not defined for the speech quality on call basis itself but for the group call duration 
according to the definitions for an intentionally terminated group call in clause 6.14.5.3. 

6.14.4 Group Call Speech Quality on Sample Basis 

6.14.4.1 Abstract Definition 

The group call speech quality on sample basis is an indicator representing the quantification of the end-to-end speech 
transmission quality of the group call service. This parameter computes the speech quality on a sample basis. 

NOTE 1 : The acoustic behaviour of terminals is not part of this speech quality measurement. 

NOTE 2: The speech quality in group calls is measured at any receiving B -party, i.e. at every group member in 

receiving state. Thus, speech quality for one audio sample may vary among the receiving B -party UEs. It 
is up to the following analysis to aggregate and evaluate the different results. 

6. 1 4.4.2 Abstract Equation 

The applicability of a suitable speech quality evaluation method for the narrow-band speech codec within TETRA 
networks is for further study. 

6.14.4.3 Trigger Points 

The group call speech quality on sample basis is derived from the speech samples transmitted during the duration of the 
entire group call. Trigger points are therefore not defined for the speech quality on sample basis itself but for the group 
call duration according to the definitions for an intentionally terminated group call in clause 6.14.5.3. 
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6.14.5 Group Call Cut-off Call Ratio [%] 
6.14.5.1 Abstract Definition 

The group call cut-off ratio denotes the probability that a successful call attempt is ended by a cause other than the 
intentional termination by the A- or B -party. 

NOTE: In TETRA a B -party may in special situations request a group call disconnection. Those instances should 
be excluded from the group call cut-off call ratio. 



6.14.5.2 Abstract Equation 



Group Call Cut - off Call Ratio [%] = 



unintentionally terminated group calls 
all successful group call attempts 



xlOO 



6.14.5.3 Trigger Points 

TETRA: 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description/protocol part 


Successful group call 
attempt 


Start: The acoustic and/or 
optical indication is given to 
the A-party user that the 
group call is established. 


Start: 

Layer 3 (CMCE): The "D-CONNECT" message is sent 
from the SwMI to the A-party. 

AT: The "AT+CTCC" indication is received by the A-party. 


Intentionally terminated 
group call 


Stop: Final release of PTT 
button by any group member 
(A-party or involved 
B-parties). 


Stop: 

Layer 3 (CMCE): The last "U-TX CEASED" message is 
sent by the latest active party. 

AT: The last "AT+CUTXC=1" command is sent by the 
latest active party. 


Unintentionally terminated 
group call 


A premature call 
disconnection 


Stop trigger not reached. 


NOTE 1 : A group call may contain several phases of exchanging speech samples between A-party and B-parties. 

Within the speech transmission phases the roles of A-party and involved B-parties vary in terms of speech 

transmission originating or terminating side. 
NOTE 2: For the group call cut-off call ratio all actively involved B-parties, i.e. other group members connected to the 

established group call, are considered reflecting the end-to-end experience of the participating group call 

members, i.e. users. 



6.14.6 Group Call Speech Transmission Delay [s] 
6.14.6.1 Abstract Definition 

The group call speech transmission delay describes the time period between a UE sending speech data and the group 
member UEs receiving the speech data for a unique talk burst or speech sample within a successfully established group 
call. 

NOTE: The speech transmission delay in group calls is measured from the initiating A-party to any receiving 
B-party, i.e. to every group member in receiving state. Thus, the speech transmission delay for one 
instance of audio may vary among the receiving B-parties. It is up to the following analysis to aggregate 
and evaluate the different results. 
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6.14.6.2 Abstract Equation 



Group Call Speech Transmission Delay [s] = (^Bjisten ~ ^A,speak 



6.14.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
customer's point of view 


Technical description/protocol part 


tA, speak: Time of sending 
speech at the A-party 


Start: A-party issues a talk 
burst. 


Start: 

Audio interface: A unique audio signal is sent by the 
A-party. 


tBjisten: Time of receiving 
speech at the B-party 


Stop: B-party hears the talk 
burst. 


Stop: 

Audio interface: The very same audio signal is received by 
the B-party. 


NOTE: Since every audio signal has certain duration and is therefore sent over a period of time, start and stop trigger 
points should both either refer to the beginning or the end of this audio signal. In case the speech transmission 
delay is derived from the transmission of speech samples the same applies to this particular kind of audio 
signal. 



7 Store-and-forward (S&F) Services QoS Parameters 

The "Store-and-forward" concept can be used for every non realtime service called "Background Class", which uses the 
following communication concept. Two clients are assumed and one or more servers in the middle for each service. 

• The A-party uploads a message to a server. 

• This server forwards the message to another server (this step is optional). 

• The server notifies the B-party that a new message is available (this step is optional). 

• The B-party downloads the message. 

The customers experience is similar for all services which follow the "Store-and-forward" approach. 

At the beginning of each service-dependent clause, Figure 52 is given in an aligned version according to the respective 
service. The parameter names are aligned accordingly. Empty parameter boxes mean that the parameter is not yet 
defined. 

7.1 Generic Store-and-forward Parameters 

The QoS parameter concept presented in this clause should be used for all services that work as described in the 
introduction of clause 7 and are not defined already in a separate clause. Especially services that use proprietary or 
encrypted communication between the user equipment and the server of the service are predestinated to use the 
following generic parameter concept. 

7.1.1 Parameter Overview Chart 

Figure 52 gives an overview of the QoS parameters and their trigger points used in this generic parameter concept. The 
blue part describes the upload part of a message from the A-party to a server. The green part describes the notification 
part. The B-party will be informed about a new message. At the end the message will be downloaded at the B-party side 
from a server, described by the orange boxes. 
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Figure 55: Generic Store-and-forward Parameter Overview 
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7.1 .2 {Service} Message Upload Session Failure Ratio [%] 

7.1 .2.1 Abstract Definition 

The message upload session failure ratio describes the proportion of unsuccessful message upload sessions and message 
upload sessions that were started successfully. The upload is successful if the message is marked as sent. 

7.1 .2.2 Abstract Equation 



{ Service} Message Upload Session Failure Ratio [%\ = 



unsuccessful message upload sessions 
all message upload session start attempts 



-xlOO 



7.1.2.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload session start attempt 


A-party initiates the message upload by pushing the "send" 
message button. 


Successful message upload session 


Message upload successfully completed. 


Unsuccessful message upload session 


Stop trigger point not reached. 



7.1 .3 {Service} Message Upload Session Time [s] 

7.1.3.1 Abstract Definition 

The message upload session time describes the time period needed to successfully complete a message upload session. 

7.1.3.2 Abstract Equation 



{ Service }MessageUploadSession Time [s] = 



-t 



sLiccessfulmessageupload session messageuploadsession start attempt 



)[s] 



7.1.3.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload session start attempt 


A-party initiates the message upload by pushing the "send" 
message button. 


Successful message upload session 


Message upload successfully completed. 



Precondition for measurement: Message upload shall be successful. 

7.1 .4 {Service} Message Upload Access Failure Ratio [%] 
7.1 .4.1 Abstract Definition 

The message upload access failure ratio describes the probability that the customer cannot successfully establish a data 
connection to the message server to upload messages. 
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7.1 .4.2 Abstract Equation 



{ Service } Message Upload Access Failure Ratio [%] = 



unsuccessful message upload accesses 
all message upload access attempts 



xlOO 



7.1.4.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload access attempt 


A-party initiates the message upload by pushing the "send" 
message button. 


Successful message upload access 


Message upload starts. 


Unsuccessful message upload access 


Stop trigger point not reached. 



7.1 .5 {Service} Message Upload Access Time [s] 

7.1 .5.1 Abstract Definition 

The message upload access time describes the time period needed to estabhsh a data connection to the message server, 
from sending the initial query to the message server to the point of time when the message upload starts. 

7.1 .5.2 Abstract Equation 



{ Service } Message Upload Access Time [s] = 

(^successful message upload access ^message upload access attempt ) 1-^] 



7.1.5.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload access attempt 


A-party initiates the message upload by pushing the 
"send" message button. 


Successful message upload access 


Message upload starts. 



Precondition for measurement: Message upload access shall be successful. 

7.1 .6 {Service} Message Upload Data Transfer Cut-off Ratio [%] 

7.1 .6.1 Abstract Definition 

The message upload data transfer cut-off ratio describes the proportion of unsuccessful message uploads and message 
uploads that were started successfully. 

7.1 .6.2 Abstract Equation 



{Service} Message Upload Data Transfer Cut - off Ratio [%] = 
unsuccessful message uploads 



all successfully started message uploads 



XlOO 
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7.1.6.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started message upload 


Message upload starts at A-party side. 


Successful message upload 


Message upload successfully completed. 


Unsuccessful message upload 


Stop trigger point not reached. 



7.1 .7 {Service} Message Upload Data Transfer Time [s] 

7.1 .7.1 Abstract Definition 

The message upload data transfer time describes the time period from the start to the end of the complete message 
upload. 

7.1 .7.2 Abstract Equation 



{ Service } Message Upload Data Transfer Time [s] = 

successful message upload ^ successfully started message upload ) t^-l 



7.1.7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started message upload 


Message upload starts at A-party side. 


Successful message upload 


Message upload successfully completed. 



Precondition for measurement: Message upload data transfer shall be successful. 

7.1 .8 {Service} Notification Start Failure Ratio [%] 

7.1 .8.1 Abstract Definition 

The notification start failure ratio describes the probability that the notification download by the B -party is not 
successfully initiated after the successful upload of the message by the A-party. 

7.1 .8.2 Abstract Equation 



{Service} Notification Start Failure Ratio [%\ = 

unsuccessful notification download attempts by B - party 
all successful message uploads by A - party 



xlOO 



7.1.8.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successful message upload by A-party 


Message upload successfully completed by A-party. 


Notification download attempt by B-party 


Notification download is initiated (automatically or manually) 
at B-party side. 


Unsuccessful notification download attempt by 
B-party 


Stop trigger point not reached. 
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7.1 .9 {Service} Notification Start Time [s] 

7.1 .9.1 Abstract Definition 

The notification start time describes the time period from the successful message upload by the A-party to the start of 
the notification download attempt by the B -party. 

7.1 .9.2 Abstract Equation 



{ Service } Notification Start Time [s] = 

notification download attempt by B-party ^ successful message upload by A-party 



7.1.9.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successful message upload by A-party 


Message upload successfully completed by A-party. 


Notification download attempt by B-party 


Notification download is initiated (automatically or manually) 
at B-party side. 



Precondition for measurement: Notification download attempt shall be successful. 

7.1.10 {Service} Notification Download Session Failure Ratio [%] 

7.1.10.1 Abstract Definition 

The notification download session failure ratio describes the proportion of unsuccessful notification downloads and 
notification downloads that were started successfully. 

7.1 .10.2 Abstract Equation 

{Service} Notification Download Session Failure Ratio [%] = 

unsuccessful notification download sessions 

xlOO 

all notification download session start attempts 



7.1.10.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download session start attempt 


Notification download is initiated (automatically or manually) 
at B-party side. 


Successful notification download session 


Notification download successfully completed. 


Unsuccessful notification download session 


Stop trigger point not reached. 



7.1 .1 1 {Service} Notification Download Session Time [s] 
7.1 .1 1 .1 Abstract Definition 

The notification download session time describes the time period needed to successfully complete a notification 
download session. 
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7.1 .1 1 .2 Abstract Equation 

{ Service } Notification DownloadSession Time [s] = 

successful notification download session ^ notification download session start attempt 



7.1 .1 1 .3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download session start attempt 


Notification download is initiated (automatically or manually) 
at B-party side. 


Successful notification download session 


Notification download successfully completed. 



Precondition for measurement: Message Notification Download shall be successful. 

7.1 .12 {Service} Notification Download Access Failure Ratio [%] 

7.1.12.1 Abstract Definition 

The notification download access failure ratio describes the probability that the customer cannot successfully establish a 
data connection to the message server to download the notification of a new message. 

7.1 .12.2 Abstract Equation 

{Service} Notification Download Access Failure Ratio [%] = 

unsuccessful notification download accesses , 

xlOO 

all notification download access attempts 



7.1.12.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download access attempt 


Notification download is initiated (automatically or manually) 
at B-party side. 


Successful notification download access 


Notification download starts. 


Unsuccessful notification download access 


Stop trigger point not reached. 



7.1 .13 {Service} Notification Download Access Time [s] 

7.1.13.1 Abstract Definition 

The notification download access time describes the time period needed to estabhsh the data connection to the message 
server, from sending the initial query to the message server to the point of time when the notification download starts. 

7.1.13.2 Abstract Equation 

{ Service } Notification Download Access Time [s] = 

successful notification download access ^ notification download access attempt ) [ ^ ] 
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7.1.13.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification download access attempt 


Notification download is initiated (automatically or manually) 
at B-party side. 


Successful notification download access 


Notification download starts. 



Precondition for measurement: Notification download access shall be successful. 

7.1 .14 {Service} Notification Download Data Transfer Cut-off Ratio [%] 

7.1.14.1 Abstract Definition 

The notification download data transfer cut-off ratio describes the proportion of unsuccessful notification downloads 
and notification downloads that were started successfully. 

7.1 .14.2 Abstract Equation 

{Service} Notification Download Data Transfer Cut - off Ratio [%] = 

unsuccessful notification downloads 

xlOO 

all successfully started notification downloads 



7.1 .14.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started notification download 


Notification download starts at B-party side. 


Successful notification download 


Notification download successfully completed. 


Unsuccessful notification download 


Stop trigger point not reached. 



7.1 .15 {Service} Notification Download Data Transfer Time [s] 

7.1.15.1 Abstract Definition 

The notification download data transfer time describes the time period from the start to the end of the complete 
notification download. 

7.1 .15.2 Abstract Equation 

{ Service } Notification Data Transfer Time [s] = 

successful notification download ^ successfully started notification download ) t ^ ] 



7.1.15.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started notification download 


Notification download starts at B-party side. 


Successful notification download 


Notification download successfully completed. 



Precondition for measurement: Notification data transfer shall be successful. 



ETSI 



192 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



7.1 .16 {Service} Message Download Session Failure Ratio [%] 

7.1.16.1 Abstract Definition 

The message download session failure ratio describes the proportion of unsuccessful message download sessions and 
message download sessions that were started successfully. 

7.1 .16.2 Abstract Equation 

{Service} Message Download Session Failure Ratio [%] = 

unsuccessful message download sessions 

xlOO 

all message download session start attempts 



7.1.16.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message download session start attempt 


Message download is initiated (automatically or manually) at B-party 
side. 


Successful message download session 


Message download successfully completed. 


Unsuccessful message download session 


stop trigger point not reached. 



7.1 .17 {Service} Message Download Session Time [s] 

7.1.17.1 Abstract Definition 

The message download session time describes the time period needed to successfully complete a message download 
session. 

7.1 .17.2 Abstract Equation 

{Service} Message DownloadSession Time [s] = 

successful message download session ^ message download session start attempt 



7.1 .1 7.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message download session start attempt 


Message download is initiated (automatically or manually) 
at B-party side. 


Successful message download session 


Message download successfully completed. 



Precondition for measurement: Message download shall be successful. 

7.1 .18 {Service} Message Download Access Failure Ratio [%] 
7.1.18.1 Abstract Definition 

The message download access failure ratio describes the probability that the customer cannot successfully establish a 
data connection to the message server to download messages. 
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7.1 .18.2 Abstract Equation 



{Service} Message Download Access Failure Ratio 
unsuccessful message download accesses 



all message download access attempts 



xlOO 



7.1.18.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message download access attempt 


Message download is initiated (automatically or manually) 
at B-party side. 


Successful message download access 


Message download starts. 


Unsuccessful message download access 


Stop trigger point not reached. 



7.1 .19 {Service} Message Download Access Time [s] 

7.1.19.1 Abstract Definition 

The message download access time describes the time period needed to estabhsh a data connection to the message 
server, from sending the initial query to the message server to the point of time when the message download starts. 

7.1 .19.2 Abstract Equation 



{ Service } Message Download Access Time [s] = 

successful message download access ^ message download access attempt 

)[s] 



7.1.19.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message download access attempt 


Message download is initiated (automatically or manually) 
at B-party side. 


Successful message download access 


Message download starts. 



Precondition for measurement: Message download access shall be successful. 

7.1 .20 {Service} Message Download Data Transfer Cut-off Ratio [%] 

7.1 .20.1 Abstract Definition 

The message download data transfer cut-off ratio describes the proportion of unsuccessful message downloads and 
message downloads that were started successfully. 

7.1 .20.2 Abstract Equation 



{Service} Message Download Data Transfer Cut - off Ratio [%\ = 
unsuccessful message downloads 



all successfully started message downloads 



-XlOO 
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7.1.20.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started message download 


Message download starts at B-party side. 


Successful message download 


Message download successfully completed. 


Unsuccessful message download 


Stop trigger point not reached. 



7.1 .21 {Service} Message Download Data Transfer Time [s] 

7.1 .21 .1 Abstract Definition 

The message download data transfer time describes the time period from the start to the end of the complete message 
download. 

7.1 .21 .2 Abstract Equation 

{ServicejMessageDownloadData Transfer Time [s] = 

successfulmessagedownload ^ successfully started message download 



7.1.21.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Successfully started message download 


Message download starts at B-party side. 


Successful message download 


Message download successfully completed. 



Precondition for measurement: Message download data transfer shall be successful. 

7.1 .22 {Service} Notification and Message Download Failure Ratio [%] 

7.1 .22.1 Abstract Definition 

The notification and message download failure ratio describes the probability that the customer cannot download first 
the notification and thereafter the complete message with the UE. User reaction times are not considered. 

7.1 .22.2 Abstract Equation 

{Service} Notification and Message Download Failure Ratio [%] = 

unsuccessful notification and message downloads , 

xlOO 

all notification and message download attempts 



7.1.22.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification and message download attempt 


Notification download is initiated (automatically or manually) 
at B-party side. 


Successful notification and message download 


Message download successfully completed. 


Unsuccessful notification and message download 


Stop trigger point not reached. 
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7.1 .23 {Service} Notification and Message Download Time [s] 
7.1 .23.1 Abstract Definition 

The notification and message download time describes the time period from the start of the notification download to the 
end of the reception of the whole message content. User reaction times are not considered. 



7.1 .23.2 Abstract Equation 



{ Service } Notification and Message Download Time [s] = 

successful notification and message download ^ notification and message download attempt ) [ ^ ] 



7.1.23.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Notification and message download attempt 


Notification download is initiated (automatically or 
manually) at B-party side. 


Successful notification and message download 


Message download successfully completed. 



Precondition for measurement: Notification and message download shall be successful. 



7.1 .24 {Service} End-to-End Failure Ratio [%] 



7.1 .24.1 Abstract Definition 

The end-to-end failure ratio describes the probability that the complete service usage from the start of the message 
upload at the A-party to the complete message download at the B-party cannot be completed successfully. This 
transmission is unsuccessful if the message upload, the notification (if possible) or the message download fails. 



7.1 .24.2 Abstract Equation 



{Service} End - to - End Failure Ratio [%] = 

unsuccessful message downloads by B - party 
all message upload attempts by A - party 



xlOO 



7.1.24.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload attempt 


A-party initiates the message upload by pushing the 
"send" message button. 


Successful message download 


Message download successfully completed at B-party 
side. 


Unsuccessful message download 


stop trigger point not reached. 



7.1 .25 {Service} End-to-End Time [s] 



7.1 .25.1 Abstract Definition 

The end-to-end time describes the time period needed for the complete service usage, from the start of the message 
upload at the A-party to the complete message download at the B-party. 
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7.1.25.2 Abstract Equation 

{Service} End - to - End Time [S] = (t^^^eessM message download - tmessageuploadattempt ) 



7.1.25.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Message upload attempt 


A-party initiates the message upload by pushing the 
"send" message button. 


Successful message download 


IVIessage download successfully completed at B-party 
side. 



Precondition for measurement: End-to-end service usage shall be successful. 

7.1 .26 {Service} Login Non-Accessibility [%] 

7.1 .26.1 Abstract Definition 

The login non-accessibility describes the probability of a login failure between the message client and the message 
server. The login is needed to prepare the client of the B-party to be able to receive new notifications or messages. The 
parameter does not consider an actual message transfer. 

7.1 .26.2 Abstract Equation 



{ Service} Login Non - Accessibihty [% J = x 100 

all login attempts 



7.1.26.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Login attempt 


B-party starts login to message server. 


Successful login 


Login procedure successfully completed. 


Unsuccessful login 


Stop trigger point not reached. 



7.1 .27 {Service} Login Access Time [s] 

7.1.27.1 Abstract Definition 

The login access time describes the time period from starting the login procedure to the point of time when the login 
procedure is successfully completed and the client can receive notifications or messages at the B-party side. 

7.1.27.2 Abstract Equation 

{Service} Login Access Time [s] = {t,^,,,,,tnno^, -t,^^, 

attempt / L'^J 



7.1.27.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's point of view 


Login attempt 


B-party starts login to message server. 


Successful login 


Login procedure successfully completed. 



Precondition for measurement: Login shall be successful. 
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7.2 E-mail 

7.2. 1 Parameter Overview Chart 

Figure 53 to 56 give an overview of the QoS parameters used in the e-mail concept based on the SMTP, IMAP4 and 
POPS protocol. 
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E-mail End-to-end Failure Ratio 



Figure 56: End-to-end Session Overview 
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Figure 57: SMTP Overview 
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Figure 58: IMAP 4 (including idle feature) Parameter Overview 
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Figure 59: POPS Parameter Overview 
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7.2.2 E-Mail {Download|Upload} Service Non-Accessibility [%] 

This parameter was removed due to major changes in the e-mail QoS concept. 

7.2.3 E-Mail {Download|Upload} Setup Time [s] 

This parameter was removed due to major changes in the e-mail QoS concept. 

7.2.4 E-Mail {Download|Upload} IP-Service Access Failure Ratio [%] 

This parameter was replaced by the "Login Non- Accessibility" parameter specified in clause 7.2.11. 

7.2.5 E-Mail {Download|Upload} IP-Service Setup Time [s] 

This parameter was replaced by the "Login Non- Accessibility" parameter specified in clause 7.2.12. 

7.2.6 E-mail {Upload|Download} Session Failure Ratio [%] 

7.2.6.1 Abstract Definition 

The e-mail session failure ratio describes the proportion of unsuccessful sessions and sessions that were started 
successfully. 

7.2.6.2 Abstract Equation 



^ .wxT t t.T^ t t.r^ . X- .1 . unsuccessful sessions 

E - mail {Upload I Download} Session Failure Ratio [%] = x 100 

all session start attempts 



7.2.6.3 Trigger Points 

Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Session start attempt 


Start: A-party starts login to the 
e-mail server. 


Start: 
TCP: 

First "SYN" sent by the client. 


Successful session 


Stop: E-mail upload successfully 
completed by A-party. 


Stop: 

SMTP: Reply code "250 message accepted" 
received by the client. 

An e-mail upload session can consist of several 
uploads. 


Unsuccessful session 


Stop trigger point not reached. 
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Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Session start attempt 


Start: B-party starts login to the e- 
mail server. 


Start: First TCP "SYN" sent by the client. 


Successful session 


Stop: E-mail download successfully 
completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client as an answer to the "RETR" 
command. 

IMAP4: 

"OK FETCH completed" received by the client. 

An e-mail download session can consist of 
several FETCH/RETR/TOP requests (body 
and/or header downloads). All successful 
requests shall be confirmed accordingly. 


Unsuccessful session 


Stop trigger point not reached. 



Remark: 

• The PS bearer has to be active in the cell used by a customer (see clause 5.1) and the UE has to be attached 
(see clause 5.3) as well as the respective PDF context has to be activated (see clause 5.5). 

7.2.7 E-mail {Upload|Header Download|Download} Session Time [s] 

This parameter was removed due to the fact that the significance of the parameter is weak due to the following factors: 

• Different e-mail client implementations behave quite differently during a session with respect to the 
POP3/IMAP4 commands they send to the e-mail server. 

• In certain use cases (e.g. header download first) user interaction is required to resume the session. 
Both points have considerable influence on the measured results. 

7.2.8 E-mail {Upload|Header Download| Download} Mean Data Rate 
[kbit/s] 

7.2.8.1 Abstract Definition 

The e-mail mean data rate describes the average data transfer rate measured throughout the entire connect time to the e- 
mail service. The data transfer shall be successfully terminated. 



7.2.8.2 Abstract Equation 



E - mail {Upload I Dow^nload} Mean Data Rate [kbit/s] = 
user data transferred [kbit] 



succes sM data transfer succes sfully started data transfer 
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7.2.8.3 Trigger Points 



upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: E-mail upload starts. 


Start: 
SMTP: 

"MAIL FROM" sent by the client. 


Successful data transfer 


Stop: E-mail upload successfully 
completed by A-party. 


Stop: 
SMTP: 

Reply "250 message accepted" received by the 
client. 


Header Download: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: Header download starts. 


Start: 
POPS: 

"TOP" command sent by the client. 
IMAP4: 

"UID FETCH" command sent by the client to 
request the header. 


Successful data transfer 


Stop: Header download 
successfully completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client. 

IMAP4: 

"OK FETCH completed" received by the client. 

A header download can consist of several 
FETCH/TOP requests. All successful requests 
shall be confirmed accordingly. 


Download: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: E-mail download starts. 


Start: 
POPS: 

"RETR" command sent by the client. 
IMAP4: 

"UID FETCH" command sent by the client to 
request header and body. 


Successful data transfer 


Stop: E-mail download successfully 
completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client. 

IMAP4: 

"OK FETCH completed" received by the client. 

An e-mail download can consist of several 
FETCH/RETR requests. All successful requests 
shall be confirmed accordingly. 
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Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) , the UE 
has to be attached (see clause 5.3), the respective PDP context has to be activated (see clause 5.5) and the login to the e- 
mail server was successful (see clause 7.2.11). 

7.2.9 E-mail {Upload|Header DownloadI Download} Data Transfer Cut-off 
Ratio [%] 

7.2.9.1 Abstract Definition 

The e-mail data transfer cut-off ratio describes the proportion of unsuccessful data transfers and data transfers that were 
started successfully. 

7.2.9.2 Abstract Equation 



E - mail {Upload I Header Download I Download} Data Transfer Cut - off Ratio [%] = 

unsuccessful data transfers 

xlOO 

all successfully started data transfers 



7.2.9.3 Trigger Points 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Teclinical description/protocol part 


Successfully started data transfer 


Start: E-mail upload starts. 


Start: 
SMTP: 

"MAIL FROM" sent by the client. 


Successful data transfer 


Stop: E-mail upload successfully 
completed by A-party. 


Stop: 
SMTP: 

Reply "250 OK, message accepted" received by 
the client. 


Unsuccessful data transfer 


Stop trigger point not reached. 
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Header Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: Header download starts. 


Start: 
POPS: 

"TOP" command sent by the client. 
IMAP4: 

"UID FETCH" command sent by the client to 
request the header. 


Successful data transfer 


Stop: Header download 
successfully completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client as an answer to the "TOP" 
command. 

IMAP4: 

"OK Fetch complete" received by the client. 

A header download can consist of several 
FETCH/TOP requests. All successful requests 
shall be confirmed accordingly. 


Unsuccessful data transfer 


Stop trigger point not reached. 


Download: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Teclinical description/protocol part 


Successfully started data transfer 


Start: E-mail download starts. 


Start: 
POPS: 

"RETR" command sent by the client. 
IMAP4: 

"UID FETCH" command sent by the client to 
request header and body. 


Successful data transfer 


Stop: E-mail download successfully 
completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client as an answer to the "RETR" 
command. 

IMAP4: 

"OK Fetch complete" received by the client. 
An e-mail download can consist of several fetch 
requests. All successful requests shall be 
confirmed by "OK Fetch completed". 

An e-mail download can consist of several 
FETCH/RETR requests. All successful requests 
shall be confirmed accordingly. 


Unsuccessful data transfer 


Stop trigger point not reached. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) , the UE 
has to be attached (see clause 5.3), the respective PDP context has to be activated (see clause 5.5) and the login to the e- 
mail server was successful (see clause 7.2.11). 
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7.2.10 E-mail {Upload|Header Download|Download} Data Transfer Time [s] 

7.2.10.1 Abstract Definition 

The e-mail data transfer time describes the time period from the start to the end of the complete transfer of e-mail 
content. 

7.2.1 0.2 Abstract Equation 



E - mail {Upload I Header Download I Download} Data Transfer Time [s] = 

successful data transfer ^ successfully started data transfer 

)[s] 



7.2.10.3 Trigger Points 



Upload: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: E-mail upload starts. 


Start: 
SMTP: 

"MAIL FROM" sent by the client. 


Successful data transfer 


Stop: E-mail upload successfully 
completed A-party. 


Stop: 
SMTP: 

Reply "250 message accepted" received by the 
client. 


Header Download: 


Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: Header download starts. 


Start: 
POPS: 

"TOP" command sent by the client. 
IMAP4: 

"UID FETCH" command sent by the client to 
request the header. 


Successful data transfer 


Stop: Header download 
successfully completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client. 

IMAP4: 

"OK Fetch completed" received by the client. 

A header download can consist of several 
FETCH/TOP requests. All successful requests 
shall be confirmed accordingly. 
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Download: 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Successfully started data transfer 


Start: E-mail download starts. 


Start: 
POPS: 

"RETR" command sent by the client. 
IMAP4: 

"DID FETCH" command sent by the client to 
request header and body. 


Successful data transfer 


Stop: E-mail download successfully 
completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client as an answer to the "RETR" 
command. 

IMAP4: 

"OK Fetch completed" received by the client. 

An e-mail download can consist of several 
FETCH/RETR requests. All successful requests 
shall be confirmed accordingly. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) , the UE 
has to be attached (see clause 5.3), the respective PDP context has to be activated (see clause 5.5) and the login to the e- 
mail server was successful (see clause 7.2.11). 



7.2.1 1 E-mail Login Non-Accessibility [%] 



7.2.1 1 .1 Abstract Definition 

The e-mail login non-accessibility describes the probability that the e-mail client is not able to get access to the e-mail 
server. 



7.2.1 1 .2 Abstract Equation 



^ -IT • XT A -1 v. r^n unsuccessful logins 

E - mail Login Non - Accessibility [%] = — xlOO 

all login attempts 
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7.2.11.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Login attempt 


Start: User starts login to the e-mail 
server. 


Start: 
TCP: 

First "SYN" sent by the client. 


Successful login 


Stop: Login procedure successfully 
completed. 


Stop: 
SMTP: 

Reply "235 Authentication successful" received 
by the client as an answer to the authentication 
request. 

IMAP4: 

Reply "OK AUTHENTICATE successful" 
received by the client as an answer to the 
authentication request. 

POPS: 

"+0K" received by the client as an answer to 
the authentication request. 


Unsuccessful login 


Stop trigger point not reached. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) and the 
UE has to be attached (see clause 5.3). 

7.2.12 E-mail Login Access Time [s] 

7.2.12.1 Abstract Definition 

The e-mail login access time describes the time period from starting the login procedure to the point of time when the 
client is authenticated. 

7.2.1 2.2 Abstract Equation 



E - mail Login Access Time [s] = (t ,,,,,, .^nogin " t login attempt 
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7.2.12.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Login attempt 


Start: User starts login to the e-mail 
server. 


Start: 
TCP: 

First "SYN" sent by the client. 


Successful login 


Stop: Login procedure successfully 
completed. 


Stop: 
SMTP: 

Reply "235 Authentication successful" received 
by the client as an answer to the authentication 
request. 

IMAP4: 

Reply "OK AUTHENTICATE successful" 
received by the client as an answer to the 
authentication request. 

POPS: 

"+0K" received by the client as an answer to 
the authentication request. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) and the 
UE has to be attached (see clause 5.3). 

7.2.13 E-mail Notification Push Failure Ratio [%] 
7.2.13.1 Abstract Definition 

The e-mail notification push failure ratio describes the probability that the notification announcement was not 
successfully conveyed to the B-party. 



7.2.13.2 Abstract Equation 



E - mail Notification Push Failure Ratio [%] = 

unsuccessful attempts to push the notification to the B - party 
all attempts to push the notification to the B - party 



xlOO 



7.2.13.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Notification pusli attempt 


Start: Not applicable. 


Start: 
IMAP4: 

"EXISTS" command received by the client. 


Successful idle complete 


Stop: Not applicable. 


Stop: 
IMAP4: 

"OK IDLE complete" received by the client. 


Unsuccessful idle complete 


Stop trigger point not reached. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) , the UE 
has to be attached (see clause 5.3), the respective PDP context has to be activated (see clause 5.5), the login to the e- 
mail server was successful (see clause 7.2.11) and the e-mail upload was successful (see clause 7.2.6). 
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7.2.14 E-mail Notification Push Transfer Time [s] 



7.2.14.1 Abstract Definition 

The e-mail notification push transfer time describes the time period from starting the notification push to the successful 
confirmation of the e-mail server of the end of the idle period. 



7.2.14.2 Abstract Equation 

E - mail Notification Push Transfer Time [s] = (ts^ecessM idle complete - 1 notification push attempt )[s] 



7.2.14.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


Notification push attempt 


Start: Not applicable. 


Start: 
IMAP4: 

"EXISTS" command received by the client. 


Successful idle complete 


Stop: Not applicable. 


Stop: 
IMAP4: 

"OK IDLE complete" received by the client. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) , the UE 
has to be attached (see clause 5.3), the respective PDP context has to be activated (see clause 5.5), the login to the e- 
mail server was successful (see clause 7.2.11) and the e-mail upload was successful (see clause 7.2.6). 



7.2.15 E-mail End-to-End Failure Ratio [%] 



7.2.15.1 Abstract Definition 

The e-mail end-to-end failure ratio describes the probability that the complete service usage from the start of e-mail 
upload at the A-party to the complete e-mail download at the B -party with an e-mail client cannot be completed 
successfully. This transmission is unsuccessful if the e-mail upload, the header download (if applicable) or the e-mail 
download fails. 



7.2.1 5.2 Abstract Equation 



^ 1 ^ iT- i • unsuccessful e - mail downloads by B - party 

E - mail End - to - End Failure Ratio [%] = — 100 

all e - mail upload attempts by A - party 
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7.2.15.3 Trigger Points 



Event from abstract equation 


Trigger point from customer's 
point of view 


Technical description/protocol part 


E-mail upload attempt by A-party 


Start: A-party starts login to the 
e-mail server. 


Start: 
TCP: 

First "SYN" sent by the client. 


Successful e-mail download by 
B-party 


Stop: E-mail download successfully 
completed by B-party. 


Stop: 
POPS: 

Termination sequence <CRLF.CRLF> received 
by the client. 

IMAP4: 

"OK FETCH completed" received by the client. 

An e-mail download can consist of several 
FETCH/RETR requests. All successful requests 
shall be confirmed accordingly. 


Unsuccessful e-mail download by 
B-party 


Stop trigger point not reached. 



Preconditions for measurement: The PS bearer has to be active in the cell used by a customer (see clause 5.1) and the 
UE has to be attached (see clause 5.3). 

7.2.16 Exemplary Signal Flow 

The following signal flows are examples. The signalling between client and server can differ. It depends on the used 
client and server type. 



7.2.16.1 SMTP E-mail Upload 





Trigger 


CLIENT 


SERVER 


TCP connection setup 


1 


SYN 






2 




SYN, ACK 




3 


ACK 




Request for capabilities 


4 


EHLO 




5 




250 Hello 
[...capability list...] 


Authentication 


6 


AUTH [...1 






7 




334 






. ..authentication challenge between client and server. . . 




8 




235 Authentication successful 


E-mail upload 


9 


MAIL FROM:<name@domain.com> 




10 




250 OK 




11 


RCPT TO:<name2@domain.com> 






12 




250 OK 




13 


DATA 






14 




354 Start mail input 






. . . header and body data is sent from client to server. . . 




15 


<CRLF>.<CRLF> | 




16 


1250 OK, message accepted 


Logout 


17 


QUIT 




18 




221 Closing connection 
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7.2.16.2 IMAP4 Idle Header and E-mail Download 





Trigger 


Client 


Server 


TCP connection setup 


1 


SYN 






2 




SYN, ACK 




3 


ACK 






4 




* OK IMAP server ready 


Request for capabilities 


5 


001 CAPABILITY 






6 




* CAPABILITY [...capability list...] 




7 




001 OK CAPABILITY complete 


Authentication 


8 


002 AUTHENTICATE [...] 






9 




+ Go ahead 






. ..authentication cfiaiienge between client and server. . . 




10 




002 OK AUTHENTICATE successful 


Synchronisation 


1 1 


003 LIST 






12 




* LIST[...] 




13 




003 OK LIST completed 




14 


004 SELECT "INBOX" 






15 




* 2 EXISTS 




16 




* RECENT 




17 




* FLAGS (\Seen [..]) 




18 




f-1 




19 




004 OK SELECT complete 


Activation idle mode 


20 


005 IDLE 






21 




+ IDLE 






. . . time passes; new mail arrives at server. . . 


New e-mail arrived at the 


22 




* 3 EXISTS 


server 


23 


DONE 






24 




005 OK IDLE complete 


Request for DID number, 


25 


006 FETCH 3 (UID) 




method differs 


26 




' 3 FETCH (UID 4711) 




27 




006 OK FETCH complete 


Header download 


28 


007 UID FETCH 471 1 BODY[HEADER] 






29 




* 471 1 FETCH (BODY[HEADER] 
{123} 




30 




Date: [...] 
From: [...] 
Subject: [...] 
To:[...] 
cc:[...] 

Message-Id: [...] 




31 




007 ok FETCH completed 


E-mail Header and body 
download 


32 


008 UID FETCH 4711 (UID FLAGS 
BODY.PEEK[]) 






33 




* 1 FETCH (UID 4711 FLAGS 
(\Recent) Body [] {123456} 




34 




Return-Path: name@domain.com 






. . . header and body data is sent from server to client. . . 




35 




008 OK FETCH completed 


Delete 


36 


009 UID STORE 471 1 +flaqs \deleted 






37 




* 3 FETCH (FLAGS (\Seen \Deleted)) 




38 


009 OK +FLAGS completed 




39 


010 EXPUNGE 






40 




01 OK Expunge completed 


Logout 


41 


01 1 LOGOUT 






42 




* Bye 




43 




01 1 OK LOGOUT completed 
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7.2.1 6.3 POPS Header Download 





Trigger CLIENT 


SERVER 


TCP connection setup 


1 


SYN 




2 




SYN, ACK 


3 


ACK 


4 




+0K P0P3 server ready 


Request for capabilities 


5 


AUTH 




6 




+0K List of supported SASL 
authentication methods follows: 
[...authentication mechanism list...] 


7 


CAPA 




8 




+0K Capability list follows: 
[...capability list...] 


Autlientication 


9 


AUTH [...] 






. ..authentication chaiienge between client and server. . . 


10 




+0K 1 message, 1 500 octets 


Synchronisation 


11 


STAT 




12 




+0K 1 1500 


13 


LIST 




14 




+0K Scan list follows 
1 1500 

<CRLF>.<CRLF> 


E-mail header download 


15 


TOP 1 




16 




+0K Message top follows 






. . . Iieader data is sent from server to client. . . 




17 


i<CRLF>.<CRLF> 


Logout 


18 


QUIT 




19 




+0K 
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7.2.1 6.4 POPS E-mail Download 





Trigger CLIENT 


SERVER 


TCP connection setup 


1 


SYN 




2 




SYN, ACK 


3 


ACK 


4 




+0K Server ready 


Request for capabilities 


5 


AUTH 




6 




+0K List of supported SASL 
authentication methods follows: 
[...authentication mechanism list...] 


7 


CAPA 




8 




+0K Capability list follows: 
[...capability list...] 


Autlientication 


9 


AUTH [...] 






. ..authentication chaiienge between client and server. . . 


10 




+0K 1 message, 1 500 octets 


Synchronisation 


11 


STAT 




12 




+0K 1 1500 


13 


LIST 




14 




+0K Scan list follows 
1 1500 

<CRLF>.<CRLF> 


15 


UIDL 




16 




+0K Scan list follows 
1 12 

<CRLF>.<CRLF> 


E-Mail header and body 
download 


17 


RETR 1 




18 




+0K 1 500 octets 




. . . tieader and body data is sent from server to client. . . 


19 




<CRLF>.<CRLF> 


Delete 


20 


DELE 1 




21 




+0K Message deleted 


Logout 


22 


QUIT 






23 




+0K Closing connection 



7.3 Multimedia Messaging Service (MMS) 

NOTE 1 : It is important to keep in mind tliat measurement equipment and tecliniques used can affect tlie data 

collected. The measurement equipment and techniques should be defined and their effects documented 
for all tests. One example of this is the effect of Windows RAS on the setup of PDP Context (see [5]). 

NOTE 2: Please be aware that the underlying transport mechanism can either be WAP 1.x or WAP2.0. 
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7.3.1 Parameter Overview Chart 



parameters 



trigger point? 
customer's 



teclinical 
trigger points 
for success ' 



MMS Send Failure Ratio 



MMSSandTim^ 




message button at 
A-party side 



message upload at 
A-party side 



PDP context 
activation 



message upload at 
A-party side 



Upload of the first 
data packet 
containing content. 



t4 



Reception of final 

acknowledgement 

for the last data 

packet contain ing^ 

content 

t5 




MMS 

Notification 
Failure Ratio 



MMS Notification 
Time 



See notification is 
received at B-party 
side 



Client requests the 
message 



PDP context 
activation 



tlO 

Reception of the 
first data packet 
containing message 
content 



See incoming 
message data at B- 
party side 



MMS Retrieval Failure Ratio 



MMS Retrieval Time 



til 

Message is 
received completely 
at B-party side 



See complete 
message at B-party 
side 



MMS End to End Failure Ratio 



MMS End to End Delivery Time 



Figure 60: MMS Parameter Overview with Trigger Points 
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7.3.2 MMS Send Failure Ratio [%] 

7.3.2.1 Abstract Definition 

The parameter MMS Send Failure Ratio describes the probabihty that a MMS -message cannot be send by the 
subscriber, although he has requested to do so by pushing the "send button". 

7.3.2.2 Abstract Equation 



nv>n.>roo i i • n unsuccessful MMS scnQ attcmpts 

MMS Send Failure Ratio [%] = 100 

all MMS send attempts 



7.3.2.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


MMS Send Attempt 


Pushing of send button. 


The send button initiates the PDF context activation of the 
MS (MO), followed by a connection to the WAP Gateway, 
and to the MMSC. (See trigger 1 in Figure 61). 


Unsuccessful MMS Send 
Attempt 


Do not see "Message 
sent". 


The m-send.conf (see [2]) (where Response 

Status: $80 = M_RS_OK) is not received by the MS(MO). 

(See trigger 1 8 in Figure 61 ). 

(See notes 1 to 3). 

"MMS unsuccessful send attempt timeout" as specified 
inn.ll. 


NOTE 1 : The phase where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 2: A forwarding of a MMS without reception of a positive m-send.conf (where Response Status: 
$80 = M_RS_OK) shall be counted as failure. 

NOTE 3: Only MMS sent within the timeouts will be considered. 
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Legend 
Control Plane 
WAP Layers 

(WAP1.X/WAP2.0) 

MMS Layer 



— activate pdp context REQUEST >» 

—-activate pdp context ACCEPT o 

--wsp connect REQUEST / TCP SYN »> 

-wsp connect REPLY /TCP SYN ACK o 

wtp ACK / TCP ACK »> 

MIVIS m-send.req >>> 



—MMS m-send.conf- 



-wsp DISCQNNECT (WAPl.x only)-- 



7 

10 

12 

13 

16 

17 

20 

22 

23 

25 

MMS m-notification.ind 

«< activate pdp context REQUEST- 

activate pdp context ACCEPT 

«< wsp connect REQUEST / TCP SYN- 

o wsp connect REPLY / TCP SYN ACK— 

«< wtp ACK / TCP ACK 

«< -WSP/HTTP Get REQUEST 

m-retrieve.conf 



— m-notifyResp.ind- 



-wsp DISCONNECT (WAPl.x only)- 



Figure 61 : MMS Transaction flow (immediate retrieval) 

NOTE: In Figure 61 only the transaction flow for immediate retrieval is shown. Please refer to Figure 5 in [2] for 
the delayed retrieval transaction flow. 

7.3.3 MMS Retrieval Failure Ratio [%] 
7.3.3.1 Abstract Definition 

The parameter MMS Retrieval Failure Ratio describes the probability that the MMS -message cannot be downloaded by 
the MT mobile, which received a MMS notification before. 
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Remark: 

• The MMS notification is a push-message. This message either initiates the download of the MMS content by 
starting a "WAP Get Request" (when the mobile is switched to automatic mode) or enables the user to 
manually start this "Wap Get Request" (when the mobile is switched to manual mode). The measurements will 
be done either using the setting "Automatic Download" (e.g. the download follows the immediate retrieval 
transaction flow) or following the delayed retrieval. In case of delayed retrieval the wait time between the 
notification response (m-notifyResp.ind) and the WSP/HTTP get request (WSP/HTTP Get.req) must be set to 
zero. Please refer to Figure 5 in [2] for the delayed retrieval transaction flow. 

7.3.3.2 Abstract Equation 



iv>riv>roT^ 1. 1 . uHsucccssful MMS deliverv attcmpts 

MMS Delivery Failure Ratio [%] = — x 100 

all MMS delivery attempts 



7.3.3.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


MMS Retrieval Attempt 
(MT) 


Start: Initiation of the 
Wap Get Request MT. 


Start: After the m-Notification.ind. (see [2]) has been sent 
to the MS (MT), this mobile activates a PDP-context and 
contacts the MMSC via the WAP Gateway (See 
trigger 29 in Figure 61). 


Unsuccessful MMS 
Retrieval Attempt (MT) 


Stop: No MMS-message is 
received. 


Stop (immediate retrieval): The m-notifyResp.ind (see [2]) 
is not sent by the MS (MT). (See trigger 49 in Figure 61 ). 
(See notes 1 and 2). 

"MMS unsuccessful Retrieval timeout" as specified in 
TS 102 250-5 [i.1]. 

Stop (deferred retrieval): The m-acknowledge.ind\s not 
sent by the MS (MT). 


NOTE 1 : The phase where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 2: Only MMS received within the timeouts will be considered. 



7.3.4 MMS Send Time [s] 

7.3.4.1 Abstract Definition 

A subscriber uses the Multimedia Messaging Service (as indicated by the network ID in his mobile phone display). The 
time elapsing from pushing the send button after the editing of a MMS-message to the completion of the data transfer is 
described by this parameter. 

NOTE: Possible measurement scenarios for time indicators of MMS may vary in the number of involved 
MMSCs. With increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs 
involved will increase also. Number of MMSCs involved is therefore a measurement condition to be 
discussed. 

7.3.4.2 Abstract Equation 



MMS Send Time [S] = (tMMStoMMSCcomplete - tsendButton)[s] 
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7.3.4.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


sendButton 


Start: Send button is 
pushed. 


Start: The send button initiates the PDF context activation 
of the MS(MT), followed by a connection to the WAP 
Gateway 

(See trigger 1 in Figure 61). 
(see notes 1 and 2). 

"MMS unsuccessful send transfer timeout" as specified in 
TS 102 250-5 [i.1]. 


MMStoMMSCcomplete 


Stop: MMS-message is 
completely transmitted to 
MMS-C. 


Stop: The m-send.conf (see [2]) (where Response 
Status: $80 = M_RS_OK) is received by the MS(MO). 
(see trigger 18 in Figure 61). 


NOTE 1 : The phase, where the WAP session WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be 

deactivated is not covered by this indicator. Some mobiles might not support the sending/receiving of 
the next MMS unless the WAP session WAP session (WAP1 .x) / TCP connection (WAP 2.0) is 
disconnected properly. 

NOTE 2: Only MMS send within the timeouts will be considered. 



7.3.5 MMS Retrieval Time [s] 

7.3.5.1 Abstract Definition 

The reception of a MMS-message works as follows: A push-sms is sent to the receiver's mobile. In automatic mode, the 
push sms initiates a WAP-connection to download the MMS from the MMS-C. The initiation of the WAP connection is 
called the WAP GET REQUEST (WGR). The time elapsing between the WGR and the completion of the download of 
the MMS will be described by the parameter MMS Retrieval Time. 

Possible measurement scenarios for time indicators of MMS may vary in the number of involved MMSCs. With 
increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs involved will increase also. 
Number of MMSCs involved is therefore a measurement condition to be discussed. 

7.3.5.2 Abstract Equation 



MMS Delivery Time [s] = (tMMSfromMMsccompiete - tinitWGR)[s] 



7.3.5.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Teclinical description/protocol part 


initWGR 


Start: Time when WAP Get 
Request is initiated. 


Start: The m-Notification.ind (see [2] is delivered to the 
MS (MT). This initiates the PDF context activation. 
(See trigger 29 in Figure 61). 


MMSfromMMSCcomplete 


Stop: MMS-message is 
received completely. 


Stop (immediate retrieval): The m-notifyResp.Ind (see [2]) 
is sent by the MS (MT). (See trigger 49 in Figure 61). 
(see notes 1 and 2) 

"MMS successful retrieval timeout" as specified in 
TS 102 250-5 [i.1]. 

Stop (deferred retrieval): The m-acknowledge.ind \s sent 
by the MS (MT). 


NOTE 1 : The phase, where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 2: Only MMS received within the timeouts will be considered. 
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7.3.6 MMS Notification Failure Ratio [%] 

7.3.6.1 Abstract Definition 

The parameter MMS Notification Failure Ratio [%] describes the probability that the Multimedia Messaging 
Service (MMS) is not able to deliver the Notification of a MMS-message to the b-parties mobile. 

7.3.6.2 Abstract Equation 



MMS Notification Failure Ratio [%] 



failed MMS - notifications 
successfully submitted MMS 



xlOO 



7.3.6.3 Trigger Points 



Event from abstract 
equation 


Trigger point from 
user's point of view 


Technical description/protocol part 


Successfully submitted 
MMS MO 


Start: Reception of the 
acknowledgement from 
the MMS-C MO 
(i.e. "Message sent"). 


Start: The m-send.conf (see [2]) (where Response 
Status: $80 = M_RS_OK) is not received by the MS(MO). 
(See trigger 18 in Figure 61). 
(see notes 1 and 2) 


Failed MMS-Notifications 


Stop: Failure delivery 
(non-delivery) of the 
Notification-SMS. 


Stop: m- notification. ind (see [2]) is not delivered to the 
MS(MT). 

(See trigger 28 in Figure 61). 
(See note 3) 

"MMS successful notification timeout" as specified in 
TS 102 250-5 [i.ll. 


NOTE 1 : The phase where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 2: Only the accepted MMS has to be considered (see the response status = $80 in the sendconf) 
MMS with negative response but delivered can added alternatively. 

NOTE 3: Only Notifications received within the timeouts will be considered as successful. 



7.3.7 MMS Notification Time [s] 
7.3.7.1 Abstract Definition 

A subscriber uses the Multimedia Messaging Service. The time elapsing from the complete submission of the 
Multimedia-Message to the MMSC to the reception of the Notification (MT) is the MMS Notification Delay. 

Possible measurement scenarios for time indicators of MMS may vary in the number of involved MMSCs. With 
increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs involved will increase also. 
Number of MMSCs involved is therefore a measurement condition to be discussed. 



7.3.7.2 Abstract Equation 

MMS Notification Time [s] = (t^^^Notif " tMMSsubmit ) [s] 



ETSI 



221 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



7.3.7.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


MMSsubmit 


Start: The MMS is 
submitted successfully. 


Start: The m-send.conf (see [2]), (where Response 
Status: $80 = M_RS_OK) is received by the MS(MO). 
(See trigger 18 in Figure 61). 
(See note 1). 


recNotif 


Stop: Time when the 
notification is received 
(MT). 


Stop: M-Notification.ind (see [2]) is received by MS (MT) 
(See trigger 28 in Figure 61). 
(See note 2). 

"MMS successful notification timeout" as specified in 
TS 102 250-5 [i.1]. 


NOTE 1 : The phase, where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 2: Only Notifications received within the timeouts will be considered as successful. 



7.3.8 MMS End-to-End Failure Ratio [%] 

7.3.8.1 Abstract Definition 

The parameter MMS end-to-end failure ratio describes the probability that the Multimedia Messaging Service (MMS) is 
not able to deliver a MMS-message after the "send button" has been pushed or the MO party has not received an 
acknowledgement of the successful transmission from the MMSC. 

7.3.8.2 Abstract Equation 



MMS End - to - End Failure Ratio [%] = 



unsuccessfully delivered MMS - messages 
all MMS send attempts 



xlOO 



End-to-end parameter measurement may optionally be derived by concatenating the component measurements. 

7.3.8.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


MMS Send Attempt by 
MS(MO) 


Start: Pushing of send 
button. 


Start: The send button initiates the PDF context activation 
of the MS, followed by a connection to the WAP Gateway. 
(See trigger 1 in Figure 61). 
(See note 1). 


Unsuccessful MMS 
Retrieval Attempt of 
MS(MT) 


Stop: No MMS-message is 
received (MT) or no 
acknowledgement from the 
MMSC is received at MS 
(MO). 


Stop: The m-send.conf (where Response 
Status: $80 = M_RS_OK) is not received by the MS (MO) 
or the m-notifyResp.ind (\n case of immediate retrieval) 
respectively the m-acklowledge.'\n6 (in case of deferred 
retrieval, see also [2]) is not sent by the MS (MT). See 
trigger 18 and 49 in Figure 61 and notes 2 and 3. 
MMS unsuccessful end-to-end timeout as specified in 
TS 102 250-5 [i.1]. 


NOTE 1 : The forwarding of a MMS by the MMSC to the MS (MT) might be possible without the reception of the 
m-send.conf MS (MO) (see [2]), (where response status is $80 = M RS OK). 

NOTE 2: The phase where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 
covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS 
unless the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 3: Only MMS received within the timeouts will be considered. 
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7.3.9 MMS End-to-End Delivery Time [s] 
7.3.9.1 Abstract Definition 

A subscriber uses the Multimedia Messaging Service (as indicated by the network ID in his mobile phone display). The 
time elapsing from pushing of the "send button" to the reception of the MMS by the b-parties mobile is the MMS 
End-to-end Delivery Time. 

This parameter is not calculated if the MO party has not received an acknowledgement of the successful transmission 
from the MMSC. 

The size of a MMS varies. In comparison to SMS, the size has noticeable impact on the submission time. So, a typical 
sized MM should be used for this measurement (see [i.l]). 

NOTE 1 : Possible measurement scenarios for time indicators of MMS may vary in the number of involved 
MMSCs. With increasing MMS-traffic or internetwork-traffic surveillance, the number of MMSCs 
involved will increase also. Number of MMSCs involved is therefore a measurement condition to be 
discussed. 

NOTE 2: End-to-end parameter measurement may optionally be derived by concatenating the component 
measurements. 



7.3.9.2 Abstract Equation 

MMS End - to - End Delivery Time [s] = (t^MSrec " tsendAttempt 



7.3.9.3 Trigger Points 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


sendAttempt 


Start: Time when the "send 
button" is pushed. 


Start: The send button initiates the PDP context activation 
of the MS (MO), followed by a connection to the WAP 
Gateway. 

(See trigger 1 in Figure 61). 
(See note 1). 


MMSrec 


Stop: Time when the MMS is 
received at the b-parties 
mobile. 


Stop: The M-retrieve.conf (see [2]) is received completely 
by the MS (MT), and the MS (MT) sends the 
m-NotifyResp.ind 

(See trigger 49 in Figure 61 in case of immediate retrieval) 
respectively the m-ackiowiedgeAnd (in case of deferred 
retrieval). 

(See notes 2 to 4). 

"MMS successful End-to-end timeout" as specified in 
TS 102 250-5 [i.l]. 


NOTE 1 : The forwarding of a MMS by the MMSC to the MS (MT) might be possible without the reception of the 
m-send.confMS (MO). 

NOTE 2: Parameter not calculated if the m-send.conf (where Response Status: $80 = M_RS_OK) is not received 
by MS (MO) (See trigger 18 in Figure 61). 

NOTE 3: The phase where the WAP session (WAP1 .x) / TCP connection (WAP 2.0) will be deactivated is not 

covered by this indicator. Some mobiles might not support the sending/receiving of the next MMS unless 
the WAP session (WAP1 .x) / TCP connection (WAP 2.0) is disconnected properly. 

NOTE 4: Only MMS received within the timeouts will be considered. 
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7.4 Short Message Service (SMS) , Short Data Service (SDS) 

The Short Message Service (SMS) is available in GSM/UMTS networks, whereas the Short Data Service (SDS) is available in TETRA networks. For both types of services the 
actual user defined data is referred as short message in the following. 

NOTE: Four types of SDS are defined in EN 300 392-2 [27], SDS type 1 to SDS type 4. SDS type 1 offers 16 bit user defined data, SDS type 2 offers 32 bit user defined 
data, SDS type 3 offers 64 bit user defined data, and SDS type 4 offers user defined data bits up to a maximum length of 2039 bit. SDS type 4 also offers an 
additional SDS Transport Layer (TL) protocol, which enhances the service provided by the layer 3 SDS protocol to provide protocol mechanisms for end-to-end 
acknowledgement, store and forward and to ensure that applications using this service interpret the user data in the same way. 
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7.4.1 Parameter Overview Chart 




A-party 
side 



trigger points 
customer's 
view 



teclinical 
trigger points 
for success 



I 



trigger points 
customer'! 




Push "Send" 
message button at 
A-party side 



First data packet is 
uploaded by the A- 
party side 

t1 



See start of 
message upload at 
A-party side 



Upload of the first 
data packet 
containing content. 

t2 



See end of 
message upload 
A-party side 



Reception of final 

acknowledgement 

for the last data ^ 

packet containing 

content 

t3 



download starts *1) 



See start of 
notification 
download at B-party 



t5 

Reception of the 
first data packet 
containing 
notification content 

nj 



See first incoming 
notification data at 
B-party side 



N otif icatinHI^^H 

received*!) 



See notification is 
received at B-pa^ 
side 



Client requests the 
message 



Start further 
message download 
at B-party side 



t8 

Reception of the 
first data packet 
containing message 
content 



See incoming 
message data at B- 
party side 



t9 

Message is 
received completely 
at B-party side 



See complete 
message at B-party 
side 



SMS Completion Failure Ratio 



SMS End to End Delivery Time 
*1) For the SMS service a paging is proceed within the notification phase. 

Figure 62: SMS Parameter Overview with Trigger Points 
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7.4.2 {SMS I SDS} Service Non-Accessibility [%] 



7.4.2.1 Abstract Definition 

The {SMS I SDS} service non-accessibility denotes the probabihty that the end-user cannot access the Short Message 
Service (SMS) or Short Data Service (SDS) when requested while it is offered by display of the network indicator on 
the UE. 



7.4.2.2 Abstract Equation 



{ SMS I SDS } Service Non - AccessibiUty [%] = 

unsuccessful { SMS I SDS } service attempts 
all { SMS I SDS } service attempts 



xlOO 



7.4.2.3 Trigger Points 

GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's point of 
view 


Technical description/protocol part 


SMS service attempt 


Start: 

Push send button (initiate sending an 
SMS). 


Start: 

Layer 3 (MM): The first "Access request" is sent by the 
originating UE (Figure 63, most upper signalling point). 
Detailed: CM Service Request is sent by the originating 
UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or 
text mode) command is sent by the originating TE. 


Successful SMS 
service attempt 


Stop: 

Receive the acknowledgement from the 
SMSC at the A-party. 


Stop: 

Layer 3 (SMS): The "Delivery report" is received by the 
originating UE (Figure 63, signalling point number 7b). 
Detailed: CP_DATA (RP_ACK) is received by the 
originating UE. 

AT: "OK" is received by the originating TE. 


Unsuccessful SMS 
service attempt 


Stop trigger point not reached. 
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SHS-IWHSC 



HSC or SGSN 



10a. Message 



trans fer 



10b. Delivery 



report 



3 . to r-war dSho rtHes s age 



I 

9b. Delivery report 



Access request I 

< >l 

and possible I 
authfinti cation 



7a. Message transfer 



Sa. sendlnfoFor- 

< > 

HO-SHS Z) 



7b. Delivery report 



Operation invocation or message transfer 

Successful operation invocation or message transfer including report 



NOTE 1 : Described in TS 1 24 008 [1 0] and TS 1 29 002 [1 2]. 
NOTE 2: This operation is not used by the SGSN. 



TETRA: 



Figure 63: SMS Transaction flow - Originating UE 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Tectinical description/protocol part 


SDS service attennpt 


Start: Push send button 
(initiate sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" nnessage is sent 
by the originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE, where <called party identity> provides 
a unique identification of the desired B-party and <length> is 
the size of the SDS in [bits]. 


Successful SMS service 
attennpt 


Stop: Receive the 
acknowledgennent fronn the 
SwMI at the initiating party. 


Stop: 

Layer 2 (LLC): The "BL-ACK" message is received at the 
originating UE. 

AT: "OK" is received by the originating TE. 


Unsuccessful SMS service 
attennpt 


Stop trigger point not reached. 


NOTE: The "BL-ACK" nnessage is related to the Logical Link Control (LLC) protocol whereas the "U-SDS-DATA" 
nnessage is related to the Circuit Mode Control Entity (CMCE) protocol. 
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Figure 64: SDS signalling flow chart 



Remark: 

• In TETRA, the SDS type and parameters relating to the message are set with a previous " AT+CTSDS 
<AI service>, <area>, <e-to-e encryption>, <access priority>, <called party identity type>" command. 

7.4.3 {SMS SDS} Access Delay [s] 

7.4.3.1 Abstract Definition 

The {SMS I SDS} access delay is the time period between sending a short message to the network and receiving a send 
confirmation from the network at the originating side. 

7.4.3.2 Abstract Equation 



{ SMS I SDS } Access Delay [s] = (t^ - 1^,,,,, ) [s] 



7.4.3.3 Trigger Points 

GSM/UMTS: 
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Event from abstract 
equation 


Trigger point from user's point of 
view 


Technical description/protocol part 


^A,send 


Start: 

Push send button (initiate sending an 
SMS). 


Start: 

Layer 3 (MM): The first "Access request" is sent by the 
originating UE (Figure 63, most upper signalling point). 
Detailed: CM Service Request is sent from the originating 
UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or 
text mode) command is sent by the originating TE. 


^A, receive 


Stop: 

Acknowledgement from tlie SMSC is 
received at tine A-party. 


Stop: 

Layer 3 (SMS): The "Delivery report" is received by the 
originating UE (Figure 63, signalling point number 7b). 
Detailed: CP_DATA (RP_ACK) is received by the 
originating UE. 

AT: "OK" is received by the originating TE. 



TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^A,send 


Start: Push send button 
(initiate sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" message is sent 
by the originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE, where <called party identity> provides 
a unique identification of the desired B-party and <length> is 
the size of the SDS in [bits]. 


^A, receive 


Stop: Receive the 
acknowledgement from the 
SwMI at the initiating party. 


Stop: 

Layer 2 (LLC): The "BL-ACK" message is received at the 
originating UE. 

AT: "OK" is received by the originating TE. 


NOTE: The "BL-ACK" message is related to the Logical Link Control (LLC) protocol whereas the "U-SDS-DATA" 
message is related to the Circuit Mode Control Entity (CMCE) protocol. 



7.4.4 {SMS I SDS} Completion Failure Ratio [%] 

7.4.4.1 Abstract Definition 

The {SMS I SDS} Completion Failure Ratio is the ratio of unsuccessfully received and sent messages from one UE to 
another UE, excluding duplicate received and corrupted messages. 

A corrupted SMS (or SDS) is an SMS (or SDS) with at least one bit error in its message part. 

7.4.4.2 Abstract Equation 



{ SMS I SDS } Completion Failure Ratio [%] = 



unsuccessfully received { SMS I SDS } 
all { SMS I SDS } service attempts 



xlOO 
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7.4.4.3 Trigger Points 



GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's point of 
view 


Technical description/protocol part 


SMS service attempt 


Start: 

Push send button (Initiate sending an 
SMS). 


Start: 

Layer 3 (MM): The first "Access request" is sent by the 
originating UE (Figure 63, most upper signalling point). 
Detailed: CM Service Request is sent from the 
originating UE. 

AT: The "AT+CMGS=<len>" or 
"AT+CMGS=<MSISDN>" (parameter depends on the 
"AT+GMGF" setting, PDU or text mode) command is 
sent by the originating TE. 


Successfully received 
SMS 


Stop: 

The Short Message is received by the 
B-party's UE. 


Stop: 

Layer 3: The "Message transfer" is received in the 
terminating UE (Figure 61 , signalling point number 6). 
Detailed: CP_DATA (RP_AGK) is sent by the 
terminating UE. 

AT: The "CMTI" event received at the terminating TE. 


Unsuccessfully 
received SMS 


Stop trigger point not reached or SMS received is duplicated or corrupted. 



SC SMS-GMSC HLR MSG or SGSN VLR MS 

1 a. Messag( 
transfer 



^ 1 b. Delivery 
report 

^ Operation invocation or message transfer. 

^ — ^ Successful operation invocation or message transfer including report. 
NOTE: This operation is not used by the SGSN. 

Figure 65: SMS Transaction flow - Terminating UE 
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TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


SDS service attempt 


Start: 

Push send button (initiate 
sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" message is sent 
by the originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE, where <called party identity> provides 
a unique identification of the desired B-party and <length> is 
the size of the SDS in [bits]. 


Successfully received test 
SDS 


Stop: 

The Short Message is 
received by the terminating 
party. 


Stop: 

Layer 3 (CMCE): The corresponding "D-SDS-DATA" 
message is received by the terminating UE. 

AT: The "AT+CMTI" new message indication or the 
"AT+CTSDSR" receive notification for the corresponding 
message is received at the terminating TE (depending on 
SDS settings). 


Unsuccessfully received test 
SDS 


Stop trigger point not reached or SMS received is duplicated or corrupted. 



Remarks: 

• In GSM/UMTS, "CMGR=<n>" gives back the received SMS, or "CMGL="ALL"" or "CMGL=4" all of the 
received ones. In order to receive CMTI events they have to be activated at the B-party with the "AT+CNMI" 
command. 

• The detection of duplicated and corrupted received SMS or SDS is a post processing issue. 

• In TETRA, the Short Data Service Centre (SDSC) might modify the content of an SDS. The unique 
identification of an SDS at the receiving UE is up to the following analysis. 

7.4.5 {SMS I SDS} End-to-End Delivery Time [s] 

7.4.5.1 Abstract Definition 

The {SMS I SDS} end-to-end delivery time is the time period between sending a short message to the network and 
receiving the very same short message at another UE. 

7.4.5.2 Abstract Equation 



{ SMS I SDS } End - to - End Delivery Time [s] = (t ^ ^i,, - 1 ) [s] 



ETSI 



231 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



7.4.5.3 Trigger Points 



GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's point of 
view 


Technical description/protocol part 


^A,send 


Start: 

Push send button (Initiate sending an 
SMS). 


Start: 

Layer 3: The first "Access request" is sent by the 
originating UE (Figure 63, most upper signalling point). 
Detailed: CM Service Request is sent by the originating 
UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or 
text mode) command is sent by the originating TE. 


^B, receive 


Stop: 

The short message is received by the 
B-party's UE. 


Stop: 

Layer 3: The "Message transfer" is received by the 
terminating UE (Figure 61 , signalling point number 6). 
Detailed: CP DATA (RP ACK) is sent by the terminating 
UE. 

AT: The "GMTI" event received at the terminating TE. 



TETRA: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^A,send 


Start: Push send button 
(initiate sending an SDS). 


Start: 

Layer 3 (GMGE): The first "U-SDS-DATA" message is sent 
by the originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE, where <called party identity> provides 
a unique identification of the desired B-party and <length> is 
the size of the SDS in [bits]. 


^B, receive 


Stop: The short message is 
received by the terminating 
party. 


Stop: 

Layer 3 (GMGE): The corresponding "D-SDS-DATA" 
message is received by the terminating UE. 

AT: The "AT+CMTI" new message indication or the 
"AT+CTSDSR" receive notification for the corresponding 
message is received at the terminating TE (depending on 
SDS settings). 



7.4.6 {SMS I SDS} Receive Confirmation Failure Ratio [%] 
7.4.6.1 Abstract Definition 

The { SMS I SDS } receive confirmation failure ratio denotes the probability that the receive confirmation for a sent 
attempt is not received by the originating UE although requested. 
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7.4.6.2 



Abstract Equation 



{ SMS I SDS } Receive Confirmation Failure Ratio [%] = 
non - confirmed { SMS I SDS } receptions 



all { SMS I SDS } service attempts 



-xlOO 



7.4.6.3 Trigger Points 

GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


SMS service attempt 


Start: Pusli send button 
(initiate sending an SMS). 


Start: 

Layer 3: The first "Access request" is sent by the originating 

UE (Figure 63, most upper signalling point). 

Detailed: CM Service Request is sent by the originating UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or text 
mode) command is sent by the originating TE. 


Confirmed SMS reception 


Stop: Receive tine 
confirmation at tine initiating 
party tliat tlie message is 
received at the terminating 
party. 


Stop: 

To be defined. 


Non-confirmed SMS 
reception 


Stop trigger point not readied. 


TETRA: 


Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


SDS service attempt 


Start: Pusli send button 
(initiate sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" message carrying 
the "SDS-TRANSFER" message with Delivery report 
request "Message received report requested" or "Message 
received and consumed report requested" is sent by the 
originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE. 


Confirmed SMS reception 


Stop: Receive the 
confirmation at the initiating 
party that the message is 
received at the terminating 
party. 


Stop: 

Layer 3 (CMCE): The "D-SDS-DATA" message carrying the 
"SDS-REPORT" message with Delivery Status "SDS receipt 
acknowledged by destination" is received by the originating 
UE. 

AT: to be defined. 


Non-conformed SMS 
reception 


Stop trigger point not reached. 
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Il5d5_tran5^er req 



i5d5_lnsds_repGrt 



{message ■succes&fully 
tran-5""emec to SwHI) 



dsds_report ind 



(mes&age- received 
bydesliiiatiDn) 



risds_rEpaft ind 



{message consumed 
by destnadDn} 

1]sd5_aclc leg | 



SDS-TRANSFER 



SDS^^EPOPT 



SDS-REPORT 



SDS-ACK 



SDS-TL 



SDS-TRANSFER 



SDS-REPORT 



SDS-REPORT 



SDS-ACK 



appiicadon 



tsds trans-er ind 



tl5Q5._nepafft_ieq 



tlEe&_nepct neq 



(mes&age consumed 
by destinaftionj 



Clsd& act: '"™d 



SDSconsu-nec -epcrl 
ackiDwIedgen'ent 



If 'message 

ne<Hived' 

requested 



If "message 
consumed" 
requested 



Figure 66: SDS signalling flow chart for SDS type 4 via SDS-TL protocol according to 
EN 300 392-2 [27], clause 29.3.3 with transparent SwMI transport (SwMI store-and-forward 
functionality uses additional SDS-REPORT and SDS-ACK messages) 

7.4.7 {SMS I SDS} Receive Confirmation Time [s] 



7.4.7.1 



Abstract Definition 



The { SMS I SDS } receive confirmation time is the time period between sending a short message to the network and 
receiving the receive confirmation for this message from the network. 



7.4.7.2 



Abstract Equation 



{ SMS I SDS } Receive Confirmation Time [s] = (t 



A,receive confirmation ^A,send 
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7.4.7.3 Trigger Points 



GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^A,send 


Start: Push send button 
(initiate sending an SMS). 


Start: 

Layer 3: The first "Access request" is sent by the originating 

UE (Figure 63, most upper signalling point). 

Detailed: CM Service Request is sent by the originating UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or text 
mode) command is sent by the originating TE. 


^A,receive confirmation 


Stop: Receive tlie 
confirmation at the initiating 
party that the message is 
received at the terminating 
party. 


Stop: 

To be defined. 



TETRA: 



Event from abstract 
equation 



Trigger point from user's 
point of view 



Technical description/protocol part 



A,send 



Start: Push send button 
(initiate sending an SDS). 



Start: 



Layer 3 (CMCE): The first "U-SDS-DATA" message carrying 
the "SDS-TRANSFER" message with Delivery report 
request "Message received report requested" or "Message 
received and consumed report requested" is sent by the 
originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE. 



A,receive confirmation 



Stop: Receive the 
confirmation at the initiating 
party that the message is 
received at the terminating 
party. 



Stop: 

Layer 3 (CMCE): The "D-SDS-DATA" message carrying the 
"SDS-REPORT" message with Delivery Status "SDS receipt 
acknowledged by destination" is received by the originating 
UE. 



AT: to be defined. 



7.4.8 {SIVIS I SDS} Consumed Confirmation Failure Ratio [%] 

7.4.8.1 Abstract Definition 

The { SMS I SDS } consumed confirmation failure ratio denotes the probabiHty that the consumed confirmation for a 
sent attempt is not received by the originating UE although requested. 

7.4.8.2 Abstract Equation 



{ SMS I SDS } Consumed Confirmation Failure Ratio [%] = 
non - confirmed { SMS I SDS } consumptions 



all { SMS I SDS } service attempts 



-xlOO 
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7.4.8.3 Trigger Points 



GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


SMS service attempt 


Start: Push send button 
(initiate sending an SMS). 


Start: 

Layer 3: The first "Access request" is sent by the originating 

UE (Figure 63, most upper signalling point). 

Detailed: CM Service Request is sent by the originating UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or text 
mode) command is sent by the originating TE. 


Confirmed SMS consumption 


Stop: Receive tlie 
confirmation at the initiating 
party that the message is 
received at the terminating 
party. 


Stop: 

To be defined. 


Non-confirmed SMS 
consumption 


Stop trigger point not reached. 


TETRA: 


Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


SMS service attempt 


Start: Push send button 
(initiate sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" message carrying 
the "SDS-TRANSFER" message with Delivery report 
request "Message consumed report requested" or "Message 
received and consumed report requested" is sent by the 
originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE. 


Confirmed SMS consumption 


Stop: Receive the 
confirmation at the initiating 
party that the message is 
consumed. 


Stop: 

Layer 3 (CMCE): The "D-SDS-DATA" message carrying the 
"SDS-REPORT" with Delivery status "SDS consumed by 
destination" is received by the originating UE. 

AT: To be defined. 


Non-confirmed SMS 
consumption 


Stop trigger point not reached. 



7.4.9 {SMS I SDS} Consumed Confirmation Time [s] 

7.4.9.1 Abstract Definition 

The {SMS I SDS} consumed confirmation time is the time period between sending a short message to the network and 
receiving the consumed confirmation from the network. 

7.4.9.2 Abstract Equation 



{ SMS I SDS } Consumed Confirmation Time [s] = (t A,eo„sumedco„finnatk,n " t A,se„d ) [s] 
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7.4.9.3 Trigger Points 



GSMAJMTS: 



Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^A;send 


Start: Push send button 
(initiate sending an SMS). 


Start: 

Layer 3: The first "Access request" is sent by the originating 

UE (Figure 63, most upper signalling point). 

Detailed: CM Service Request is sent by the originating UE. 

AT: The "AT+CMGS=<len>" or "AT+CMGS=<MSISDN>" 
(parameter depends on the "AT+CMGF" setting, PDU or text 
mode) command is sent by the originating TE. 


^A,consumed confirmation 


Stop: Receive tlie 
confirmation at the initiating 
party that the message is 
consumed at the terminating 
party. 


Stop: 

To be defined. 


TETRA: 


Event from abstract 
equation 


Trigger point from user's 
point of view 


Technical description/protocol part 


^A;send 


Start: Push send button 
(initiate sending an SDS). 


Start: 

Layer 3 (CMCE): The first "U-SDS-DATA" message carrying 
the "SDS-TRANSFER" message with Delivery report 
request "Message consumed report requested" or "Message 
received and consumed report requested" is sent by the 
originating UE. 

AT: The "AT+CMGS="<called party identity>", 
<length><CR> <LF><user data><CtrlZ>" command is sent 
by the originating TE. 


^A,consumed confirmation 


Stop: Receive the 
confirmation at the initiating 
party that the message is 
consumed at the terminating 
party. 


Stop: 

Layer 3 (CMCE): The "D-SDS-DATA" message carrying the 
"SDS-REPORT" with Delivery status "SDS consumed by 
destination" is received by the originating UE. 

AT: To be defined. 
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Annex A (informative): 

Examples for measuring trigger points 

• SMS-Service: 

Layer 3 Messages: 

■ Start SMS Service Attempt: generating random access (chan_request SDCCH) at mobile 
equipment. 

■ Successful SMS Service Attempt receiving cp_data (rp_ack) at mobile equipment. 

■ Receiving SMS on Mobile Equipment 2: receiving cp_data (rp_ack) at mobile equipment. 



ETSI 



238 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



Annex B (informative): 
Streaming explanations 

RTP - Real Time Protocol: 

The Real Time Protocol is used for the transmission of real-time data, e.g. audio, video, simulation data over multicast 
or unicast network services. No QoS functionality is implemented. 

RTP is designed to be independent from the underlying transport and network layers. For a complete description refer 
to [7]. 

RTCP - Real Time Control Protocol: 

The Real Time Control Protocol as control protocol for the RTP. It allows the monitoring of the data delivery and 
provides a minimal control and identification functionality. RTCP is designed to be independent from the underlying 
transport and network layers. 

For a complete description of the RTCP refer to [7]. 

RTSP - Real Time Streaming Protocol: 

The Real Time Streaming Protocol is used for the overall control of the streaming session. 
For a complete description of the RTSP refer to [8]. 
Most important methods of RTSP: 

• DESCRIBE: The DESCRIBE method retrieves the description of a presentation or media object identified by 
the request URL from a server. It may use the Accept header to specify the description formats that the client 
understands. The server responds with a description of the requested resource. The DESCRIBE reply-response 
pair constitutes the media initialization phase of RTSP [8]. 

• SETUP: Causes the server to allocate resources for a stream and start an RTSP session [8]. 

• PLAY: Play is send from the client to the server and informs the server to start the transmission of data as 
specified by the SETUP method [8]. 

• PAUSE: Send from client to server. Temporarily halts the stream transmission without freeing server 
resources. These resources can only be freed after a specified time [8]. 

• RECORD: This method initiates recording a range of media data according to the presentation description [8]. 

• TEARDOWN: Frees resources associated with the stream. The RTSP session ceases to exist on the server [8]. 



B.1 Streaming Hyperlink Description 

The following syntax for the hyperlink is used in order to access streaming content on the server: 



protocol://address:port/path/file 



Protocol 


Used protocol. E.g. rtsp:// 


Address 


Address of the used streaming server 


Port 


Port used by the server for answering request 


Path 


Path to the file to be streamed 


File 


The streaming file to be reproduced and its extension 
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Annex C (informative): 

Push to Talk over Cellular Information 

Figures C.l to C.4 visualize signal flows of typical PoC Sessions. The figures include the signal flows on the transport 
layer as well as some restricted information on the application layer. To keep the flows concise, some signals are not 
pictured. So it is possible to obtain signal flows universally valid for different kinds of PoC Sessions. Figures C.l to C.4 
show particularities using Unconfirmed Indication with Media Buffering as well as differences between Pre-established 
and On-demand PoC Sessions. 



Terminal A 



PoC Network 



Terminal B 



User A PoC Service 
Registration 



Talk Burst Request 
(Pushing PoC button) 





SIP REGISTER 




M— 


SIP 401 Unauthorized 


— ► 




SIP REGISTER 






SIP 200 OK 


— ► 


4 — 


SIP PUBLISH 




< — 


SIP 200 OK 


— ► 



Talk Burst Granted 
indication 



Start of speech 



End of speech 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



SIP ACK 



TBCP: Talk Burst Granted 





RTP: Last Packet 






TBCP: Talk Burst Idle 


— ► 


M— 


TBCP: Talk Burst Taken 






RTP: Media Stream 






RTP: Last Packet 






TBCP: Talk Burst Idle 




4— 


SIP BYE 






SIP 200 OK 


— ► 




SIP REGISTER 




1^ 


SIP 200 OK 


— ► 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



SIP 200 OK 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



TBCP: Talk Burst Taken 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Request 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



User B Service 
Activation 



TBCP: Talk Burst Granted 



Terminal B accepts 
incoming PoC session 

<- 

End of Speech 
► 

Talk Burst Request 
(Pushing PoC button) 
<- 

^ Start of speech 



:i 



Figure C.1: On-demand PoC Session with manual-answer 
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Terminal A 



User A PoC Service 
Registration 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



Start of speech 



End of speech 



PoC Network 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



SIP 200 OK 



SIP INVITE 



SIP 200 OK 



SIP ACK 



TBCP: Talk Burst Granted 



RTF: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Taken 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



Terminal B 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



User B Service 
Activation 



SIP 200 OK 



SIP INVITE 



SIP 200 OK 



TBCP: Talk Burst Taken 



Terminal B accepts 
incoming PoC session 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Request 



TBCP: Talk Burst Granted 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



End of Speech 

Talk Burst Request 
(Pushing PoC button) 
<■ 

^ Start of speech 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



NOTE: The PoC Server supports Media Buffering and sends the Talk Burst confirm message after receiving the 
first automatic-answer message. 



Figure C.2: Unconfirmed On-demand Ad-hoc PoC Group Session with automatic-answer 
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Terminal A 



User A PoC Service 
Registration 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



Start of speech 



PoC Network 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



SIP 200 OK 



SIP INVITE 



SIP 200 OK 



SIP ACK 



TBCP: Talk Burst Granted 



RTF: Media Stream 



of Speech. 



RTP: Last Packet 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Taken 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



Terminal B 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 



SIP PUBLISH 



User B Service 
Activation 



SIP 200 OK 



SIP INVITE 



SIP 200 OK 



TBCP: Talk Burst Taken 



Terminal B accepts 
incoming PoC session 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Request 



TBCP: Talk Burst Granted 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



-End of Speec^ 



Talk Burst Request 
(Pushing PoC button) 



^ - -Start of sneecb 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



Figure C.3: Confirmed Pre-established session with manual-answer 
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Terminal A 



PoC Network 



User A PoC Service 
Registration 
► 


■ 

SIP REGISTER 


Pre-established Sessior 
initiation 


► 

SIP 401 Unauthorized 


SIP REGISTER ^ 


^ SIP 200 OK 


SIP PUBLISH ^ 


^ SIP 200 OK 


SIP INVITE ^ 


> 


STP 100 TrvHiR 


^ SIP 200 OK 


(Pushing PoC button) 
> 


bir ACK ^ 


SIP REFER ^ 




^ SIP 202 Accepted 


Talk Burst Granted 


^ TBCP: Connect 


TBCP: Acknowledged ^ 


indication 


^ TBCP: Talk Burst Granted 


M 


RTF: Media Stream ^ 


start or speech 


RTP: Last Packet ^ 




^ TBCP: Talk Burst Idle 




^ irJCr: ialKrJurst laken 




^ RTP: Media Stream 


^nd of speech 


^ RTP: Last Packet 




^ TBCP: Talk Burst Idle 




SIP BYE ^ 


II 


1 SIP 200 OK 






SIP REGISTER ^ 


1 


SIP 200 OK 





— 


SIP 401 Unauthorized 






SIP REGISTER 


> 


4— 


SIP 200 OK 






SIP PUBLISH 


— ► 


<— 


SIP 200 OK 




^ 


SIP INVITE 


— ► 



Terminal B 



SIP REGISTER 



User B Service 
Activation 



Pre-established Session 
initiation 



SIP 100 Trying 



SIP 200 OK 



SIP ACK 



TBCP: Connect 



TBCP: Acknowledged 



TBCP: Talk Burst Taken 



RTP: Media Stream 



RTP: Last Packet 



-► 



TBCP: Talk Burst Idle 



TBCP: Talk Burst Request 



TBCP: Talk Burst Granted 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



End of 



S£eec^ 



Talk Burst Request 
(Pushing PoC button) 



Start of sneech 



SIP BYE 



SIP 200 OK 



SIP REGISTER 



SIP 200 OK 



Figure C.4: Unconfirmed Pre-established session witli automatic-answer 
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C-1 Signal Grouping 

This clause defines groups of signals which will in the following be referred to as building blocks of PoC signal flows, 
or just building blocks. These building blocks are derived from [13], [14], [15], representing only parts of a complete 
signal flow as seen in Figures C.l to C.4. Here, different building blocks of the same kind correspond to the same QoS 
group. The aim of the definition of such building blocks is to give detailed information on the different signal flows. 

Remark: 



• In the QoS parameter defining clause of the present document, most signal flows shown are less detailed. The 
reason for this is that these flows are only used to visualize the relevant trigger points of the corresponding 
QoS parameter with respect to their occurrence over time. 

The relationship between building blocks and QoS groups is pictured in the following table. In contrast to the signal 
flows given to illustrate QoS parameter definition, only flows leading to a positive result are given. The only exception 
from this is the signal flow for a queued talk burst request which was added for sufficiency. 

A distinction has been made between On-demand and Pre-established PoC Sessions since here different building blocks 
are needed. Crosses are indicating the blocks needed for the corresponding QoS group. For simplicity some crosses are 
greyed. These crosses indicate that a choice between Confirmed and Unconfirmed Indication has to be made. 

Further parameters for the "Session SETUP" are the following: 

• Session SETUP alternative 1: confirmed with auto-answered on terminating side. 

• Session SETUP alternative 2: confirmed with manual answered on terminating side. 
Session SETUP alternative 3: unconfirmed with auto-answered on terminating side. 
Session SETUP alternative 4: unconfirmed with manual answered on terminating side. 

Remarks: 



• Only the QoS groups relevant to the building blocks are shown in table C.l. 

• Building blocks not related to any QoS group are omitted in table C.l. 

• Building blocks can be identified by their number as specified in table C. 1 . 
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Table C.1 : Assignment of PoC Session parts to building blocks 
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Building blocks (below) & QoS groups (right hand side) 




PoC Service Registration 


PoC Publish 


PoC On-demand Session Initiation, confirmed 


PoC On-demand Session Initiation, unconfirmed 


PoC Pre-established Session Media Parameters Negotiation 


PoC Pre-established Session Initiation, confirmed 


PoC Pre-established Session Initiation, unconfirmed 


PoC On-demand Session Initiation, User B auto-answer 


PoC On-demand Session Initiation, User B manual-answer 


PoC Pre-established Session Initiation, User B auto-answer 


PoC Pre-established Session Initiation, User B manual-answer 


Media Stream from User A to PoC Server 


Media Stream from PoC Server to User B, without Buffer 


Media Stream from User B to User A, without Buffer 


Talk Burst Request 


Queued Talk Burst Request 


Leaving PoC Session (On-demand) 


Leaving PoC Session (Pre-established) 


Deregistration 










C\J 


CO 
CO 


CO 


o 

CO 


3d 


CD 
CO 


CO 




o 


4d 


CO 
LO 


LO 


o 

LO 


CD 


o 

CD 


CO 




CO 
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C.2 PoC Service Registration 



Terminal A 



User A PoC Service 
Registration 



PoC Servers 





,STP401 Unauthori/?a 


— ► 


<— 


SIP REGISTER 




<— 


SIP 200 OK 


— ► 



C.3 PoC Publish 



Terminal A 




PoC Servers 








SIP PUBLISH 








^ SIP 200 OK 





C.4 PoC Session Initiation, Originating Part 



a) PoC On-demand Session Initiation, confirmed. 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



Terminal A 



PoC Servers 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



SIP ACK 



TBCP: Talk Burst Granted 



J] 



b) PoC On-demand Session Initiation, unconfirmed. 



Talk Burst Request 
(Pushing PoC button) 

Talk Burst Granted 
indication 



Terminal A 

1 



PoC Servers 



SIP INVITE 



SIP 200 OK (unconfirmed) 



SIP ACK 



TBCP: Talk Burst Granted 



ETSI 



246 



ETSI TS 102 250-2 V2.2.1 (2011-04) 



c) PoC Pre-established Session Media Parameters Negotiation. 



Terminal A 



PoC Servers 



Session establishment 





SIP 100 Trying 


► 


< — 


SIP 200 OK 




< — 


SIP ACK 


► 



d) PoC Pre-established Session Initiation, confirmed. 



Terminal A 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



PoC Servers 



Pre-estabHshed Session 



SIP REFER 



SIP 202 Accepted 



SIP 200 OK 



SIP NOTIFY 



SIP 200 OK 



SIP NOTIFY 



SIP 200 OK 



TBCP: Connect 



TBCP: Acknowledged 



TBCP: Talk Burst Granted 



Inviting user 



Ringing response 
received 

Invitation has been 
accepted 



< 



e) PoC pre-established Session Initiation, unconfirmed. 



Terminal A 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



PoC Servers 



Pre-estabHshed Session 



SIP REFER 





oir zuz /\cccpLcu 
SIP NOTIFY 




M- 


SIP 200 OK 






SIP NOTIFY 


-► 


<- 


SIP 200 OK 






TBCP: Connect 


-► 


M- 


TBCP: Acknowledged 






TBCP: Talk Burst Granted 


-► 



Invitation has been 
accepted 
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C.5 PoC Session Initiation, Terminating Part 



a) PoC On-demand Session, automatic answer. 



PoC Servers 



Terminal B 



SIP INVITE 



SIP 200 OK 



TBCP: Talk Burst Taken 



Terminal accepts in- 
coming PoC session 
(automatically) 



b) PoC On-demand Session, manual answer. 



PoC Servers 



Terminal B 



SIP INVITE 



SIP 180 Ringing 



SIP 200 OK 



TBCP: Talk Burst Taken 



User B accepts incoming 
^PpC session_rnanually _ 



c) PoC Pre-established Session, automatic answer. 



PoC Servers 



Terminal B 



c: 



Pre-established Session 



TBCP: Connect 



TBCP: Talk Burst Ack 



TBCP: Talk Burst Taken 



d) PoC Pre-established Session, manual answer. 



PoC Servers 



Pre-established Session 



Terminal B 

=1 



SIP INVITE 



SIP 180 Rmgmg 



SIP 200 OK 



TBCP: Talk Burst Taken 



User B accepts incoming 
^PpC session_nianually _ 
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C.6 Media Streaming 

a) First Media Stream from User A to PoC Server. 



Terminal A 



Start of speech 



RTP: Media Stream 



RTP: Last Packet 



PoC Servers 



TBCP: Talk Burst Idle 



b) First Media Stream from PoC Server to User B (without Media Buffering). 



PoC Servers 



Terminal B 



RTP: Media Stream 



RTP: Last Packet 



End of Speech 



TBCP: Talk Burst Idle 



c) Last Media Stream from User B to User A via PoC Network (without Media Buffering), including Talk Burst 
Request of User B. 



I End of_s2eech 



Terminal A 



PoC Servers 



TBCP: Talk Burst Taken 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



Terminal B 



TBCP: Talk Burst Request 



TBCP: Talk Burst Granted 



RTP: Media Stream 



RTP: Last Packet 



TBCP: Talk Burst Idle 



Talk Burst Request 
^ (Pushing^ PpC button) 



_Start of_sp_ee_ch 
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C.7 Talk Burst Request 



a) Implicit Talk Burst Request (On-demand Session Initiation). 



Terminal A 



Talk Burst Request 
(Pushing PoC button) 



Talk Burst Granted 
indication 



PoC Servers 



SIP mVITE 



SIP 180 Ringing 



SIP 200 OK 



SIP ACK 



TBCP: Talk Burst Granted 



b) Explicit Talk Burst Request. 



PoC Servers 



Terminal B 



TBCP: Talk Burst Request 



TBCP: Talk Burst Granted 



Talk Burst Request 
^ _ iPushing_PoC button) 



c) Queued Talk Burst Request. 



PoC Servers 



Terminal B 



TBCP: Talk Burst Queued (positioj ^ ' 



RTF: Media Stream 



TBCP: Talk Burst Request 



RTP: Last Packet 



TBCP: Talk Burst Confirm 



RTP: Media Stream 



Floor Grant Request 
^ -(Pushing PoC button)_ 

End of Speech^ 

_Floor_Granted2ndicatiqn ^ 

^ St^_of_s£eech 



C.8 Leaving PoC Session 

a) Leaving On-demand PoC Session. 



Terminal A 



PoC Servers 



SIP BYE 



SIP 200 OK 
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b) Leaving Pre-established PoC Session. 



Terminal A 



PoC Servers 



SIP REFER 
SIP 202 Accepted 
SIP Notify 
SIP 200 OK 



C.9 Deregistration 



Terminal A 



PoC Servers 



SIP REGISTER 



SIP 401 Unauthorized 



SIP REGISTER 



SIP 200 OK 
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